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INIRQGDUCTION 


The purpose of this document is to define and discuss the Master 
Control Program II (MCP) for the B1000 machines. The concept and 
design of the MCP wiit be discussed and the functional 
specifications of the MCP*s operations will be catalogued. 


The sort» data communication» and data management systems wiid 
not be discussed in any depth in this document. Detailed 
descriptions of these features appear in other Burroughs 
publications CSee Related Documentation below). 


RELATER QBOCUMENTATION 


Name Number 
Biog00 MCP Utilities PeSe 2212 5579 
B1000 Network Definition Language PeSe 2212 5223 
B1000 Data Nanagement Systems If P»Se 2212 5470 
Bi 800/B1700 Sort . PeSe 2201 6752 
BiO000 Software Qperationat Guide 1068731 
These specifications are written for those people with 
programming experience and a knowledge of basic software 
conceptse Those unfamiliar with operating system design wiil 


gain insight into the Burroughs philosophy of system management. 
Those individuals familiar with operating systems of other 
manufacturers or of other Burroughs machines will gain an 
understanding of the Master Control Program implemented 
specificaddy for the Burroughs 81000. 


Also included in this specification are brief descriptions of 


various Functions performed by the microcrcoded [/0 driver 
routines» These same routines are often referred to as “GI5SMO" 
and “I/0 interpreter*. The discussions are necessary for 


completeness and for a thorough understanding of the 81000 
operating system of which the I/O driver is an integral part. 


MCP If is a modular» supervisory program that assumes commons 
logically complex functions to sisplify and expedite the tasks of 
programming and system operation.» Its most important duties 
include such functions as: 


» a 


* Scheduling» initiations running» and termination of jobs 
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* Providing a symbolic means of communicating with the system 
while shielding the user from the detail of the hardware 


& Providing a family of common facilities such as management 
of input/output operations and file maintenance 


it Managing the system"s resources for optimum utilization in a 
multicprogramming environment 


SIMACHINE 


The B1000 is a smali=to~medium scale» general purpose computer 
System. Its distinguishing feature is its flexibility» made 
possible through interpretive processinge In any computer system 
a representation of any process has two components® (1) a family 
of structures representing the state of that precess» and 2) a 
series of operators able to manipulate those structures. Until 
the advent of fourth generation computers» both components were 
represented in the machine hardware itsel f. A compiler or 
Language translator transformed the source code (Ce.sge-s COBOL » 
FORTRAN) into a “machine tanguage” Cobject code) which was 
defined in terms of the hardware architectures. 


For the set of processes abide to be generated by any particular 
programming tanguage» there exists a machine architecture which 
best represents those processes. For instances COBOL is a 
characteroriented language and performs decimat arithmetic 
exclusively.» Because of its data manipulation features it might 
best utilize a machine architecture with multiwaddress operators» 
capable of performing efficient “movess™ “comparess” and simpie 
expression evatuatione On the other hands FORTRAN was designed 


to compute complex mathematical functions.» It favors a § stack 
structure for parameter passing and complex expression 
evaluation. It performs binary arithmetic and would prefer 30- 


to SO-bit word sizese 


The difficulty of designing a hardware structure capabie of 
handling two such divergent languages in the most efficient 


manner becomes apparent. It would be possibler in principle at 
least» to design the hardware in such a way as to adequately) 
represent both sets of structures. However» this would prove to 


be prohibitively expensivee The typical approach» therefore» has 
been to either design the hardware to favor one language at the 
expense of others or to design a compromise structure capable of 
handling several ianguages» but none in the most efficient 
manners The wide variety of programming Languages in current use 
has placed a great strain on the capacity of the hardware to 
efficiently execute code compitied from very different languages. 
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It is to this problem that designers of fourth generation 
software» and the B1000 in particular» have addressed themselves. 
Rather than build a particular structure into the hardwarer the 
concept of the “soft machine™ has been developed whereby the 
idead environment of structures and operators is programmatically 
simulatede 


The B1000 hardware was designed with as tittle explicit structure 
as possible. Because memory may be addressed to the biter no one 


structure is inherently favored over any other. The only 
required structure is that which wild allow the simulation of any 


“soft machine”. Thus the range of structures able to be 
represented on the B1000 is untimited. 


As stated previously» for every compiler Language there exists a 
machine architecture within which the algorithms generated by 
that compiter will best rune On the B1000 this hypotheticat 


environment is called the "S-machine™. An S~machine has been 
defined for each language such that any process may be 
represented in its most efficient or most naturat forms 


unrestrained by any arbitrary hardware confi guration» 


Compilers on the B1000 generate code files which contain €1)3 the 
iaformation necessary to initialize the appropriate S«machine at 
run timee and (2) the "S=“code" to be executed on this S-machine. 
S"code is written in Sw~fLanguage» the machine Language for an 
Smachinee Execution is achieved by the S$~code being 
interpreted» an S operator at a times by a microtprogram called 
an interpreter » 


2OETWARE 


The term “"software”» as used in this document» refers to atti 
programming supplied by the Santa Barbara Plant. When the term 
is used» it most likely is referring to programs that are written 
in a higherwtevel tanguage» This may not atways be the case» but 
typically» the tearm will refer to the compilers and utility 
programs created by the Programming Activity. 


FIRMWARE 


The firmware consists of a set of interpreters» those portions of 
the MCP which are micro~coded and reside in an entity known as 
the MICRO/MCP» and a program calted "GISMO". For each Slanguage 
a microtcoded program caited an interpreter acts upon the 
hardware and executes the compited $code as defined by the 
S“machinese The B1000 software has been implemented in such a way 


1-3 
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that any number of interpretive structures may be active in the 
system at any given times This is achieved by dynamicaily 
establishing» upon demand» the S=machine structure for any 
process. 


For instances the MCP» which is itself a program» is written in a 
highwtevel languages SDL» that is designed specifically for 
writing software. It has its own optimum environment Cthe SDL 
S"machine) consisting of, the structures and operators required 
for software applications. It has its own S~fanguage and its own 
interpreter (the SDL interpreter). Running simultaneously in the 
system may be another program written in a different tanguage 
Ce eGes CosoL). This program also has its own structure (the 
COBOL S=machine)» Slanguage» and interpreters The systems when 
executing the MCPs supervisory functions» assumes the 
architecture of the SDL S-machine and» when executing the COBOL 
instructions» takes on the COBOL S-machine structure. This 
switching of interpreters and process environments is managed 
compietely by the software and is invisibie to the user of the 
machinee 


The B1000 MCP has actually evolved to its present state. 
Originally» ali functions of the MCP were coded in SDL. 
Beginning with the 4.0 release of the softwares, the most commonly 
used routines of the MCP were written in microw~code and placed in 
GIsmo. This resuited in substantial performance improvements. 
Beginning with the Sel release of the software» these commonty 
used routines were removed from GiSM0 and placed in the entity 
mentioned previoustys» the MICRO/MCP. 


These specifications have also evoived along with the MCP. Many 

of the functions described herein are now serformed by the 
MICRO“MCP» though the function itself remains: exactly the same as 
it was when it was performed by SDL code. Since this document is 
intended to be a functionai specification of the B1000 operating 


systeme alt MCP functions are described herein. Whether the 
function is performed by SDL code or by micro code shouid be 
completely transparent to the user. Actually » the functional 


result is the same for both» but the time and resource 
requirements are not identical. The difference is therefore not 
always transparent. 


Throughout this documents the acronym “MCP* may be referring to 
the MICRO/MCP or to the SDL MCP. In cases where the distinction 
is importante “MCP" widd not be used but the two terms mentioned 
above will be. This documents then» wili actually be a 
functional specification of the operating system» as it was 
originatly intended to be» though it widt actually be describing 
two separate and distinct programs. Since GISMO is aiso a 
critical part of the operating systems the document may atso 


BL1000 MCP MANUAL 
MARK 10.0 


touch upon portions of GISMOe. 


GISMO is a micro~coded family of critical routines common to all 
processeSe GISMO may also be referred to in this document = as 
"CSM"» an acronym for Centrai Service Modute. It is a central 
module of service routines used by all programs in the system and 
performs three basic functions: 


1. Switching of controdt between ali contending processes in the 
Systems 


2e Recognition and queueing of interrupts received from the 1/0 
controls or from other processes in the system» 


3» Tnitiation and management of the I/0 controls connected to 
the machines» usually at the request of ancther precess. 


Processor allocations the switching of control between two or 
more processes» is handled by the "Micro Scheduler” module in 
GISMO. This module may be thought of as an “Outer Loop™. It has 
absolute control over the process which will be performed next on 
the system. 


Interrupt resolution consists of routines which perform certain 
functions. depending on the type of interrupt and certain other 
critical conditions. The interpreter in control senses the 
interrupt and calis upon GISNO to take the required action. 


GISM0"s service request moduie (soft 1/0) perforas the function 
of a hardware device capable of performing a menory access at the 
request of an I/0 controt. An 1/0 control on the B1000 is a 
hardware device which acts as an interface between soft I/0 and a 
peripherat device» It requests access to memory on behatf of the 
device and manages the device itself. The collection of 1/70 
controts is called the I/70 sub=systeme 


Typicat data transfer operations involve frequent but brief cails 
upon soft I/0 by the I7G submsystem. The firmware was designed 
in such a way that between the execution of any two S~operators>» 
the interpreter in control will check a flag in the processor 
Ccalied the Service Request Bit) to see if the I/D sub-system is 
demanding attentionj If it ise the interpreter passes control to 
GISMO0 which performs the necessary memory access and returns 
control to the interpreter. 
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TERMINOLOGY AND DEFINITIONS 


Before proceeding with a detailed description of what the MCP 
does and how it goes about it» it wili be necessary to define a 
number of terms and data structures. whose names are used 
familiarly throughout the document. The reader shoudd know the 
meanings of the terms» but a thorough understanding of the many 
diverse programming structures presented herein is not required. 
The structures are presented onty in the interests of 
completeness»s and as a possible aid in understanding the 
narrative descriptions of the MCP*s functions» presented in the 
dater sections of the specification. . 


MEMORY MANAGEMENT AND MENORY LINKS 


The “CP organizes and aliocates space in memory through the use 
of fietds known as memory Links. Eath Link immediately precedes 
the block of memory it describes and includes such information 
as* The size of that block of memorys the type of use Cif any) 
to which it is puts and pointers to the immediately preceding 
and succeeding Links. If the block of memory is classified as 
available Ci.e@.» not currently in use by any process)» an 
additional set of descriptors point to the Links of the prior 
available and next avaitable biocks of memory. Thus it is 
possibie to search aid dtinks or .ontly those tinks describing 
available memory. <A programmatic description is given betow: 


DEFINE MEMNORY*LINK»SIZE AS #18785 | 

DECLARE MEMORY.LINK TEMPLATE BITC(MENORY.LINK -SIZE)s 
DEFINE MEMORYs»LINK»DECLARATION AS # 

DECLARE 01 DUMMY REMAPS MEMORY.~LINK» 


2 ML.DISK DSKeADR » 

2 ML~GROUP» 
3 ML»POINTER ADDRE SS» 
3 ML~JOB.NUMBER BITC16)> 
3 MLaTYPE BITCH)» 
3 ML»SAVE BITC1)» 

2 ML.SIZE BIT{24)» 

2 MLePRIORITY.FIELD BITC3 0)» 
3 ML~DK»INTERVAL BITC1I0)» 
3 ML»CURRENT-DK.INT BITC10)» 


3 MLeINCOMINGsPRIORITY | BITC5S )» 
3 MLeRESTDENCE.PRIOGRITY BIT(5)» 


& NLARP.WHOLE — BITC&)» 

& MLeRP»FRACTION. : BIT{1)» 
2 ML.FRONT BIT(24) >» 
2 ML.BACK BIT(24) » 
2 MLeUSAGEABITS BIT(C2)» 


3 MLePREVIQUS»SCAN.TOUCH BiITC1)» 
3 ML»~CURRENT.SCAN.jTOUCH BITC1)s # 
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USEC ML.DISK 
eMLe~POINTER 
eNL-JOBeANUMBER 
oNLe TYPE 
eMLeSAVE 
oMLe $I ZE 
»MLeFRONT 
eML»~BACK 
» OF MEMORYsLINK»DECLARATIONS 


DEFINE QeMLeDECLARATION AS#DECLARE 
O02 QeMEMORYeLINK TEMPLATE 


» 02 FILLER BITCMEMORYe*LINK»SIZED 
» 02 QeMLoF.AVL ADDRESS 
, O02 QeMLeBeAVL ADDRESS 
s#e 
DEFINE 
TAKE-LO AS#0# 
» TAKE”RIGHTMOST AS#12 
Fd 
DEF INE xX TYPES FOR “ML.jTYPE* 
CODE AS #082 
, AVAILABLE AS #282 
» RNeS AS #382 
> MCP.TEMP AS HA#Z 
r USEReFILE AS RS8Z 
» SEG»DICTY AS #O#Z 
» MICROCODE - HTEX 
» DICTs»MASTER AS #88 
» QUEVE.».DIRECTORY.TYPE 
AS #92 
F MSGsBUFFERY 
AS #102 
AS #112 
° TO-BE»FORGOTTEN AS #128 
F DATA.SEG AS #1328 
» DBM»BUFFER AS #142 
TERMINATING LINK AS #15842 
° MCP.PERM AS #1682 
> PSReMEM AS #17#72. 
r MCP»IOQAT AS #18#% 
» DESK HEADER AS #1982 
, PACK»MEM AS #208% 
, SDeCNTNR AS #218% 
» SCHED.»NEM AS #22#2 
» SORT .»MEM AS #2382 
rd DC He MEN AS #2482 
, MICROCODE. NON-GVERLAYABLE AS #25#2 
» QUEVE»AVL»~BUF.V AS #262 
» DMSeDISKAHDR AS#278#2% 
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DMSe-STRUCTURE AS#28#Z 
DMS.TEMP AS #2982 
DMSeGLOBALS AS #3082 
DMSeTEMP.»LOCK-DESCR AS #312 
XM»MEMORY AS #322 
PERM»SPOseBUFF AS #332 


eV we Ye % 


"TEMPLATE" in the above description is defined as "REMAPS BASE”. 
This is not important to an understanding of memory link 


operation. "ADDRESS" is defined in the MCP symbolic as 
“BITC 24)". The word “ADDRESS” here is used as a denotation of 
memory address. Hence» “ML.BACK*" in the description above is a 


pointer to the previous memory Link and "MLe~FRONT™ is. a pointer 
to the succeeding Link. MLeSIZE will contain the size of the 
area» in bits» and MLseGROUP is valid onty if the area is in use. 
ML»POINTER widt contain the memory address of the segment 
dictionary entry associated with this memory areae Segment 
dictionaries are described in the next section. ML «J0O3 -NUMBER 
wild contain the job number of the program using the area. 
“ML » SAVE» the description of which is defined as “BOOLEAN»”" is set 
on if the memory area aust be saved on disk before it is 
overlaid. 


As can be determined by adding the sizes of the various 
coaponents» a memory dink requires 187 bits of storage spacee 
Since memory is allocated dynamically» iit is often difficudt to 
predict with any degree of accuracy exactly how much memory wild 
be required by any taske The sizes of ali memory Links involved 
must be included in the caiculations. This is discussed further 
in a later paragraph. 


SEGMENT DICIZONARIES AND SYSIEM DESCRIPIORS 


Virtuat memory is supported by allowing process segmentations. By 
segmenting codes data» and interpreters and dynamically moving a 
segment into or out of memory as required» the system is able to 
function as if it had “virtually infinite” memory capacity. The 
MCP manages this facility through three structures? Code Segment 
Dictionaries» Data Segment Dictionaries» and Interpreter Segment 
Dictionartes. Each dictionary consists of a string of system 
descriptors each of which describes one segment inctuding its 
length» tlocation and statuse As a segment is moved in or out of 
memory its dictionary entry is updated accordingty- 


At run time the MCP creates the code and data segment 
dictionaries from information in the program*s code file. The 
interpreter segment dictionary is created from the interpreter 
code file in the same manner and is referenced by an entry in the 


interpreter dictionar ye 
Clear/Start timee The 


MARK 


run 


structure 
structure of the program contains 
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f ix ed in memory at 


pointers to the code and data segment dictionaries and an index 


into the interpreter dictionary. 


given below: 


SYSTEM DESCRIPTORS 


DECLARE 


A programmatic description is 


O02 SYSTEM.DESCRIPTOR TEMPLATE BITCSY.SIZE)s 


x 
DEFINE SYs2DECLARATION AS #SY.DECLTSYSTEM.DESCRIP TOR) #7% 
DEFINE SY-DECLCX) AS #DECLAREZ 


O01 DUMMY REMAPS X»% 


02 SYIN.USE 

02 SYsMEDIA 

02 SYeLOCK | 

O02 SY-IN-PROCESS 


O02 SYeINITIAL 


02 SYeFILE 


O02 SY-DK.»FACTOR 
02 SY.SEG.PG 
02 SY-TYPE 


O02 SY-ADDRESS 
03 FILLER 
03 SY~CORE 

02 SY.»LENGTH 


«a 


<r 


BITCL)» 
BITC1)>» 
BITC1)» 
BITC1)» 


BIT(1)>» 


BITC1id». 


BITC3) 
BITC)» 
BITC4)» - 


BITC36)» 
BIT{12)>» 
BITC(24)» 
BITC2495 


nt pe Re ne oe Re re re eM Oe Tt Oe NM re HE ne EE HM OM NM MN M 7 HM HE 


TO HELP MEMORY MANAGEMENT 
O=DISK» 1=S"“MEMORY 


TRUE IF THERE IS AN 1/0 IN 
PROCESS FOR THE INFORMATION 
REPRESENTED BY THIS DESCRIPTOR. 
iF TRUE» *"SY»CORE™ CONTAINS A 
POINTER TO THE I/0 DESCRIPTOR. 
"ADDRESS" [5 READ“ONLY MOTHER 
COPY» HENCE IF "WRITE" THEN GET 
NEW DISK AND REPLACE ADDRESS. 
THE OBJECT OF THIS DESCRIPTOR 
IS A FILE WHOSE USERCOUNT MUST 
BE DECREMENTED WHEN THIS 
DESCRIPTOR I5 RETIRED. 

MEMORY DECAY FACTOR 
NMEMORYACTIVITY AUDITING 

UNITS FOR SY.LENGTH. 

BITS 

DIGITS (4 BIT) 

CHARACTERS €8 BIT) 

NORMAL DESCRIPTORS 

DISK SEGMENTS 

SYSTEM DESCRIPTORS 

SYSTEM INTRINSIC. 

INDIRECT REFERENCE 

ADDRESS GIVES RELATIVE 
DISPLACEMENT IN BITS 
{SIGNED NUMBER). 

B= MICROS 


Hound wt io wat 


SO ULE Wh © 


PORT» CHANNEL AND UNIT. 

CORE» OR ADDRESS WITHIN UNIT. 
NUNBER OF UNITS» AS DETERMINED 
BY SY.TYPE. 
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DEFINE ND»DECLARATION AS# 

DECLARE 

O02 DUMMY REMAPS NORMAL.-DESCRIPTOR BITCND.~SIZE)» 
02 NO.~DK.F ACTOR BITC 3)» 
O02 FILLER BITC6)>» 
02 ND.CORE BITC24)» 
O02 ND.TYPE . BITC 3)» 
02 ND»LENGTH BITC24)3 #3 


SY-SIZE is defined in the MCP code as eighty. Hence eighty bits 
are required to contain one segment dictionary entry» or system 
descriptor.» The use of the term “DESCRIPTOR” in B1i000 
documentation is often misteading and ambiguouse There are many 
different types of descriptor s» atl of which have different 
menory requirements and formats» Consequenti y» system 
descriptors wili always be referred to as such or as segment 
dictionary entries. 


The comments on the various fields comprising the system 
descriptor are largely self-explanatory. Perhaps some 
explanation of selected fields would be beneficial» however. 
S¥»LOCK is set true if the system descriptor describes a data 
field and if the interpreter is currently accessing the field. 
This is to avoid the situation which arises in a simple 
replacement statement where the sending and receiving fietd are 
both in overtayable segments. In order to do the replacement» 
both data segments must be in memory simultaneously. 


SYeINITIAL is true for initialized data onty. The most common 
case of this occurs when executing a ‘COBOL program and the 
programmer has used the value clause to initialize data fields 
and the data field itsetf is in an overtayabte segment. 
SY»ADDRESS may be either a disk or a memory address» depending on 
the setting of SY-MEDIA. If it is a memory address» the most 
significant twelve bits are ignoreds If it is a disk address» 
the most significant twelve bits contain the porte channel and 
unit associated with the disk address. 


TNTERPRETER MANAGEMENT» PARAMETER BLOCKS AND DICTIONARZES 


The B1000 WCP maintains a List or directory of ail files on disk. 
file stored on disk has a unique names which may consist of up to 
three fields» each of which may consist of up to ten characters» 
Associated with each file on disk is an item called a “Disk Fite 
Header™. The disk file header serves essentially to describe the 
file. ALL of this is described in detail in tater sections. 
This brief discussion is being inctuded at this point to- 
facilitate the following discussions on interpreters. 
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Included in the disk file header is a field which denotes the 
type of fite. There are separate type numbers for data files» 
code files» interpreters» and so forthe Code fites Cprograms) 
and interpreters are further described by the first disk segment — 
contained in the file. This segment is called the "Program 
Parameter Block” or the "Interpreter Parameter Block"™» 
respectively. A detailed description of the program paranter 
block is presented in a tater sections A programmatic 
description of the interpreter parameter biock is presented 
below. 


DEFINE IPB.DECLARATION AS# 
DECLARE 01 DUMMY REMAPS IPB BITC1440)» 
O02 FILLER BITC1192)» 
O02 IPBeHARDWARE CHARC1)> 
02 IPB.ARCHITECTURE.NANE CHART10)>» 
O02 [PB»COMPILER.-LEVEL BITCB)>s 
O02 IPBe-GISMO.LEVEL BIT({(8)» 
O02 IPBeARCHITECTURE.ATTRIBUTES BITC80)>» 
02 FILLER BIT(56)3 


IPBsHARDWARE will contain either an "5" or an “M"» depending upon 
whether the interpreter was generated for an S"memory or an 
M~memory processofe) All 81800"s are considered to be M-merory 
processorse IPB ARCHITEC TURE-NAME will contain the generic name 
of the compiterse such as COBOL or FORTRAN. IPBeCOMPILERs»LEVEL 
will be a number which wilt correspond to the release tevel of 
the software» as described below. IPB oMCP.LEVEL» IPB8.GISMO-LEVEL 
and IPB.»ARCHITECTURE.ATTRIBUTES are parts of the interpreter 
verification feature of the MCP. 


The Bi000 MCP includes facilities to recognize the hardware 
configuation it is executing upon and select the corresponding 
interpreter from the disk directory» Ali programs which are 
compiled for execution on a 81000 wid have an interpreter "TYPE" 
requested the program parameter block of the code file (described 
in a later section)» or the specific name of the interpreter to 
be used As explained in a tater section» the program parameter 
biock contains space for three names to be associated with an 
interpreter. For discussion purposes heres the three names will 
be referred to as the "PACK" name» the “FAMILY* name and the 
“OFFSPRING” namee 


The B1000 compilers generate the tast two names of the 
interpreter only.» The family name generated always corresponds 
to the tanguage the program is written in» such as “COBOL” or 
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“FORTRAN”. The offspring name is aiways one of the reserved 
words “INTERP"» *"DEBUG™" or "TRACE*™. At BOJ» the MCP modifies the 
offspring name by concatenating one numeric character denoting 
the compiler teved and either the character "MM" or “S" depending 
upon whether the machine is equipped with an S=memory oor an 
M~-memory processor. 


The tevel number concatenated is contained in the program 
parameter block as “PROG.COMPILER.LEVEL*. Every time the 
compilers are changed in such a manner that the interpreter must 
also be changed» the level number génerated by the compiler is 
incremented. The interpreters ara then modified accordingly and 
released to the fieid under anew name» The new name will be the 
same as the old ones except for the devel number contained in the 
names For a COBOL program which is being executed on a 
Bl720~series machine and had been compited by the 421 COBOL 
compiler » the NCP will generate "COBOL"/*INTERPIM* as the 
interpreter name to be used for the executions It should be 
noted that this feature was first included in the 4.1 software 
release. Level numbers were not included in the program 
parameter block prior to the 421 release. 


Once the interpreter name is generated» the disk directory is 
searched for the interpreter. Upon finding the interpreters the 
MCP will bring it into S“memorys» if it is not already there» and 
construct an antry in the “INTERPRETER.~}DICTIONARY™. Ald 
interpreters are reentrant on the B1000. All of this is 
described in greater detail in the paragraph which foittow. Each 
entry in the interpreter dictionary has the foltowing format. 


DEFINE ID»DECLARATION AS#DECLARE 
O11 engin RENAPS INTERPRETER. DICTIONARY» 


02 ip. ENTRY »IN.USE BOOLEAN» 
02 ID-eRSONT.jUSERCOQUNT BIT(7T )» 
02 ID-TOTAL}»USERCOUNT BITC7 3» 
O02 IDmMINMeSIZE BITC4 Je 
02 ID MAX eMeSIZE BITC(4 J» 
O02 ID-PARTIAL.-BIT BOOLE AN» 
02 ID-BLOCK.~COUNT BITC4)» 
02 FILLER BITCL19) » 
02 TD.MePRESENCESIT BOOLE AN» 
O02 ID.~M.ADOR BITCL2Z)2— 
02 ID.TOPM ; BITS )». 
O02 ID-MEDIA | BITC2)» 
02 ID»LOCK - BOODLE AN» 
02 FILLER BIT Cis)» 
02 IDeTYPE BITC4 )» 
02 ID-ADDRESS BIT(36)>» 
03 FILLER BIT{12)» 
03 ID»CORE BITC24) 
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02 IDeLENGTH BIT(2 4) 58> 


There is one entry in the interpreter dictionary for each 
interpreter presently in uses» The I/0 driver is always the first 


interpreter entered in the dictionary» the Micro MCP is” the 
second entry and SDL is always the third entry in the dictionary. 
On the Bi000» it is possible to segment interpreters. 


Consequentiy» a code segment dictionary is constructed for each 
interpreter as it is brought into memorye The system descriptor» 
the first item in the interpreter dictionary» is a pointer to the 
interpreter*s code segment dictionary. Interpreters may be 
segmenteds exactly as progrags ares The same routines in the MCP 
are used for handiing program segments and interpreter segments» 


A certain amount of information about each program currently 


being executed is maintained in memory by the MCP. The field in 
which this information is maintained ts known as the Run 
Structure Nucleus of the program. It 3s abbreviated as 


RS»NUCLEUS. In the RS»~NUCLEUS» there is an index into the 
interpreter dictionary. Atl programs being executed, at any given 
time which are using the same interpreter wiil have the same 
index in the fietd in their respective nucieus. In this. manners 
interpreter re~entrancy is accomplished. 


The remaining field in the interpreter dictionary entry will not 
be described in detail at this point. For a more detaited 
description of interpreter management» the reader is referred to 
the section of this document which deals with M~memory 
management. It should be sufficient at this point to say that 
all interpreter segments except the first are treated as ordinary 
code and are considered overlayabie. The first segment of each 
interpreter is not treated as code and is not overlayabie» 
however. 


The I/0 driver» which is considered an interpreters is an 
exception to the above statements 


CODE CILES> PROGRAN PARANETER BLOEKS AND FILE PARAMETER BLOCKS 


The code file of every program must contain two types of records 
to adiow the MCP to manage the execution of that program: the 
"File Parameter Block" CFPB)» and the “Progran Parameter Block” 
(PPB). There is one FPB for each file decdared in a program plus 
one entry for a trace file. 


The first 2880 bits (two disk segments) of every code file is the 
"Program Parameter Block” CPPB) whose format is rigiddiy defined 
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by. the MCP. Every compiler generates a PPB of the same format. 
It provides» for the MCP» all the vitai statistics of the program 
inctuding: The program's name> the name of the interpreter to 
be used during executions the relative addresses of the FPB‘s» 
IPB» code segment dictionary and data segment dictionarye memory 
requirements for the program*s executions and tracing 
information. 


At run time a working copy of the PPB is written into a temporary 
or permanent tog fas dictated by the system options). The First 
two segments of this four segment entry are an exact copy of the 
PPB from the code file. Another segment is generated by the MCP 
and documents certain features of that particular executions A 
final segment is reserved for an abnormal termination message. 


If the code file is an interpreter code fite>» it contains an 
additional segment called the “Interpreter Parameter Block", It 
contains information concerning the software compatibitity of the 
interpreter. A fieid in a program's PPB specifies under which 
interpreter it will run. When the program is scheduted for 
executions the IPB of the interpreter named in the PPB is checked 
to insure that the interpreter is compatible with both the code 
file and the system softwaree The MCP informs the system 
operator via a SPO message if the interpreter cannot run. Refer 
to the appropriate MCP listing for a programmatic descriptions 


The “File Parameter Block" CFPB) is a 2440-bit record created by 


the compiler from the user's file attribute dectarations. Its 
format is rigidly defined by the MCP» and it contains the vital 
Statistics which atliow the MCP to manage the file*s usage. When 


a job is scheduled for executions a working copy of the FPB is 
written into a permanent or temporary tog Cdepending on system 
options). In addition to recording the file*"s attributes» the 
MCP documents the use of the file during that job's execution. 
It records such information as the number of times the file was 
opened and closed? the total amount of time the file was opens 
the number of records reads the number of 1/0 errorss and the 
file type. Refer to the appropriate MCP tListing for a 
programmatic description. 


FILE INFORMATION BLOCKS 


As each file is opened by the user program» a structure known as 
a Fide Information Block C(FIB) is created in mewnory by the MCP. 
The FIB contains ali information necessary for the MCP to perfora” 
normal» requested» I/0 operations on the file. Much of the 
information in the FI8 is taken directly from the FPB. Bther 
information in the structure is inserted by the MCP» based upon 
the characteristics of the peripheral device assigned to the 
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fide. Device assignment is discussed in the section of this 
specification which describes the Open Communicate. 


— 


FIB*s vary in sizes depending upon the type of device assigned to 
the file. Due to the amount of information which must be 
maintained» a disk file FIB is much Larger than that of a card 
punch file» for exampie.» 


I/Q. descriptors and buffer memory areas are attocated and 
initialized by the NCP at the same timee There will therefore be 
one memory Link only» for each file that is active in a programe 
Buffer areas and descriptors are not normaliy shared between 
files» though the Data Management subsystems the Data 
Communications subsysteas the Relative file implementation and 
the Indexed file implemenation offer some exceptions to this . 
rule. . 


A complete structural description of the FIB wiht not be 
presented hereins due primarily to the length of the structure. 
Also» the FIB is of interest to the various portions of the 
Operating System ontys The programmatic description of the 
structure is readily avaitabtle in the MCP Listing. Sizes of 
FIB*s for the different peripherat devices are presented in the 
following table. 


File Assigned to: Ps Size in Bits — 
Reader~Sorter 742 
Printer 724 
Remote Device 557 
Tape 724 
Disk 976 
Queue 385 
Ail Other Devices 612 


RUN STRUCTURE 


The structure in memory that represents the state of any process 
is the run structure. Each process has a unique run structure. 
When a job is initialized before executions the MCP creates the 
run structure from an analysis of the program's code fite»s and 
adds certain information it witl need for management of the 
execution. Att run structures are tinked together by priority. 


Arun structure consists of a program"s data or address space» 
the MCP*s managerial space catled the run structure nucteus» and 


2710 


Bi000O MCP MANUAL 
MARK 10.0 


the file and data segment dictionaries. The program*s address 
space» residing between its base and timit registers» is that 
area of memory that may be accessed and manipulated by the 
program itself. A program’s base register is a memory address 
that marks the lower bound of its addressable space. The limit 
register specifies the upperbound. A program may not access 
memory that is outside its own base to Limit areas though this 
tenet is enforced by the interpreters and not the NCP. 


A program's address space may contain both resident = and 


overlayable data. The resident data area contains those fieids 
which will be present in memory throughout the duration of the 
execution» The overiayabie data space contains segmented data 


which may be brought into or out of memory as neededs 


RUN STRUCTURE NUCLEUS 


The Run Structure Nucteus is an area structured and maintained by 
the MCP and contains the essential information about the program. 
It resides in memory directly above the program*s Limit register 
and is accessible by the MCP and the program*s interpreter. It 
contains such information as; 


we Pointers to 


BASE AND LINIT 

SEGMENT DICTIGNARZTES CCODE AND Hit 
FILE DICTIONARY 

INTERPRETER DICTIONARY ENTRY 

NEXT RUN STRUCTURE CBY PRIORITY) 
CODE FILE ON DISK 

DISK LOCATION OF RUN STRUCTURE IF “ROLLED OUT™ 
PROGRAN*’s LOG ENTRY 

VIRTUAL DATA SPACE ON DISK 

NEXT INSTRUCTION 10 BE EXECUTED 

DMS POINTERS 


* Structures necessary for communication between the program and 
the MCP 


- fe Fieids to reflect the state of the S~-machine 


& Fietds for program switches 


o 


A programmatic description may be obtained from the MCP Listing. 
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DATA AND FILE DICTIONARIES 


The data segment dictionary resides at the end of the Run 
Structure Nucteus and is pointed to by a fietd in the nucteus.e 
If there is no segmented data and the user has not requested that 
his resident data area be initialized» then the pointer wilt be 
nulls and there wilt be no dictionary. 


Each entry in the dictionary is an 80-bit system descriptor 
pointing to one data segment. 


The Last element of a run structure is the file dictionary. 
There is one 80-bit descriptor for each decdiared file plus one 
additional descriptor for a trace file Cused for tracing).j While 
a fide is opene its dictionary entry points to the fitie*s FIB in 
memory». If a file has never been openeds its entry is null. If 
a file has been temporarily closed Cie@e» “CLOSE ROLLOUT")» its 
dictionary entry points to its FIB which has been written to 
diske After a permanent closer the file*s dictionary entry wilt 
again be null. 


RETENTRANT EROCESSING AND CODE SEGMENT DICTIONARZES 


The B1000 MCP allows reentrant processings the ability of two or 
more processes to use the same code segment dictionary and» 
thereby» the same code. The code segment€s) and code segment 
dictionary reside outside a program*’s run structures anda fietd 
in the run structure nucleus points to its code segment 


dictionary. A structure caited the segment dictionary container 
contains the information necessary to govern the use of a 
particular code segment dictionary» When a job is being 


initiated for executions the MCP determines whether or not the 
code segment dictionary desired by the job is already in use. If 


it ise that dictionary widd be used. The segment dictionary 
container reflects» among other things» the number of processes 
using the dictionary it describes. If there is more than one 


users the segment dictionary container will remain in memory 
until all users have completed execution. 
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SHE 1270 SUBSYSTEM 
This section of the specifications is a description of: 


1. i170 Descriptors 
2e GISMO Gperation 
1. Channel Tabte 
2e GISMO/Hardware Interface 
A. CA/RC Cyctes 
2- Precessor I/0 Instructions 
3. Service Request — 
4.2 Status Counts 
5- Data Transfers 
3» I/0 Chaining 
42 Disk [70 Chaining 
5- Disk I/0 Overdapped Seek 
6- Tape I/0 Chaining 
32 Monitoring of Peripheral Status 
1. I/O Assignment Tabie 
Ze Unit Mnemonics 
3e Test and Wait i/70 Operators 
4 STATUS Procedure 
Se Disk Identification - Pack Labeis 
6. Pack Information Table 
Ve Tape Labettling» Initialization and Purging 
8. Tape PE/NRZ Exchanges 
fe File Structures 
1. Conventional Files 
1. File Attributes 
2e File Naming Conventions 
3- Logical Disk Files 
4e Physical Disk Files 
1. Disk Space Alf@ocation 
2e File Access and Identification 
3e Disk File Identification 
&-e- Disk File Header 
Se Multin~mPack Files 
1. Base Packs 
2e Continuation Packs 
Se MNulti~Pack File Information Table 
&e Multi~Pack Fite General Restrictians 
6e Printer Files 
1. Logical/Physical 1/0 Relationship 
2e Logical Page Imptementation 
Ye Printer and Punch Backup Capabilities 
1. Backup File Blocking Factors 
2e Backup File Controt Information - 
34 Backup File Record Forsat 
2e Retative Files 
1. Direct Fides 
2» Data Structure 
3e Disk Initialization 
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4o File Parameter Blocks 

5e Disk Header 

6s File Information Blocks 

7. Communicate Operators 

3» Indexed Sequentiat Files 

ie Direct Fites 

22 Index Files 

3-2 Cluster Fides 

42 Data File Structure 

5- Index File Structure 

6b» Memory Structures 
1. FIB Dictionaries 
2e User Specific Information (USI) 
3m File Global Information CGLOBALS) 
4. Structure Descriptor 
5e Disk Fite Header Extension 

7. Available Space Allocation _ 

8» Index File Table Splitting 

9. Current Record Pointer 

10. Current Maintenance 

11.2 Buffer Management 

i2. Buffer Descriptor 

134 Concurrent Update Operations 

5-2 The I/0 Error Procedures 


There is some overlap between the information contained in this 
section of the specification and that contained in the Demand 
Management section of the documente The Cemand Management 
section was originatily intended to cover the management of the 
peripheral after it had been assigned to a user as a fiies the 
I/0 Subsytem section was intended to cover the management of the 
device up to that time. This division is not always possible» 
particularly in the case of disk devicess. The reader may have to 
refer to both sections of the document to find the answer to a 
specific question. 


if DESCRIPTORS 


Normal state programs request I/0 funetions in a symbolic fashion 
Ca.ge» Write a Record).j The MCP must transform these expressions 
iato explicit I/0 operators catied I1/0 descriptor se An 1/0 
descriptor attows the MCP to communicate directly with a 
peripheral device via the soft 1/0 routines of GISMD. GISMO 
manages the execution of these operators by the I[/0 subsystems. 
Each I/0 descriptor provides such information as the type of I/O 
operation requested» source or destination memory addresses» the 
device which is to execute the operators» and space for result 
information used when control is passed back to the MCP. Certain 
other fields vary. with the type of descriptor and contain 
information peculiar to its specific function. 
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Any number of I/0 descriptors may be Linked together to form a 
Single “chain” and "dispatched" in one MCP operation to lessen 
the MCP*s interaction with the I/70 subsystem. 


The transformation of togical I/0 requests to physical I/0 
descriptor manipulation is discussed in the Demand Management 
section of this specifications The discussion betow is intended 
to describe the operations performed upon the descriptor after it 
has been transformed. A programmatic description of an I/0 
descriptor is given below. This particular descriptor is typical 
of one which might be constructed for a disk file. 


DEFINE IG-DESCeDECLARATION AS #% 


DECLARE 01 DUMMY REMAPS I0.DESC 

, 02 IO-RESULT WORD 

» O03 I0.CONPLETE BIT (1) 

» O03 I0-EXCEPTION BIT €1)5 

ro 03 10.PACK.~NOT READY BIT (1) 

, O03 IO-DATA-ECCERROR BIT (1) 

° 03 FILLER BIT (1) 

» 03 LO.MENePARITYERROR ‘BIT (1) 

» 03 ID -WRITE»LOCKOUT BIT (1) 

° 03 FILLER BIT (2) 

ra 03 ID» ADDRESS -PARITY-ERROR BIT €1). 
» 03 I0sSECTOR-ADDRESS»ERROR BIT (1) 
» O03 ID-S5EEKeTIMEDUT BITt €1) 

» 03 FILLER Bit (€3} 

rs 03 IG-TRANSMISSION.~PARITY -ERROR BIT (€1) 
» 03 IGeRESULTBITsoiZ BIT (1) 

» 03 IO0.PORT.RS BIT (3) 

» 03 I0..CHANNEL»RS BIT (4) 

r 02 Id-LINK ADDRESS 

» 02 Io.oP ‘WORD 

» 03 I0-0P.M- BIT (1) 

» 03 I0.0P.W BIT (1) 

e 03 10.0P.¥ BIT (1) 

r 03 IGeD0P2E BIT €1) 

» 03 I0.0P.D BIT €1) 

» 03 I0.0P.NNN BIT (3) 

» 03 FILLER, BIT €5) 

» 03 ‘FILLER BIT (3) 

» 03 10.0P.UNIT BIT (4) 

» 02 I[0.BEGIN ADDRESS 

» 02 I0-END ADDRESS 

» 02 I10.DISK» ADDRESS ADDRESS 

r 02 I0.NeEVENTS BIT (8) 

, 03 IOM-EVENTS.1I0C BIT €1) 

» 03 I0-M»EVENTS-S1f0C BIT (1) 

ra 03 FILLER BIT €1) 

° 03 IOD.M-EVENTS-INT2M BIT C1) 


b te | 
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» 03 IODMeEVENTS.-SeINT.SENT BIT (1) 
fd 03 IQ.MeEVENTS 2M INTjSENT BIT (1) 
> 03 FILLER BIT €1) 
» 03 LOeMeEVENTS<eINTAS BIT €1) 
” 02. G0.MCP.»1I0 BIT (16) 
» 02 I10.F1IB ADDRESS 
» 02 IOeFIBsLINK ADDRESS 
» O02 IQ.BACK-LINK ADDRESS 
» 02 I10.P0RT.CHAN BIT (7) 
» 03 I0.PORT ‘BIT €3) 
” 03 ITO»CHANNEL BIT (4) 
» 02 I09.BEEN.j THRU.ERROR BIT (1) #>. 


GLSMO = THE 120 DRIVER 


With the exception of the MulticrLine Controt used on Data 
Communications configurationse on the 8100C hardware the 1/0 
controis have no direct connection with main memory. All data 
transfers between the controis and memory sust go through the 
processors GISMO is a set of micro ~coded routines whose primary 
function is to interface between the MCPs and the actuat 
hardware. This allows the MCPs to view the I/0 subsystem as an 
I/O processors The MCP can initiate I/D Descriptors and GISMD 
wilt handde initiation of the control» data transfer and 
termination. The NCPs can queue several descriptors (for 
execution by a control» by propertly setting the link fietds in 
the descriptorse and GISMO wiki initiate each one in turn. 


User programs make requests to the Micro MCP» and sometimes the 
Micro MCP must ask that the request be handied by the SeMCP» but 
in either case» the MCP wiii pass the request to GISMD who in 
turn will pass it on to the I/0 control. 


The I/0 subsystem atiows fifteen controls or channels to be 
connected to any machines After GISM0 initiates a control» it 
does not wait for completion of the operation but returns controt 
to its caller. Consequently» ones» and possibly more operations 
may be in process on the machine at any given time. At any given 
moment» however» when GISM0 is executing it may onty address one 
control. ; 


The primary cosmunication between the MCPs and GISMG is through 
the I/0 descriptors. The SeMCP wild initiate I/0 operations 
using the DISPATCH S~operator and the M.MCP contains micro ~code 
to perform a similar function. This S-operator requires two 
parameters» the port and channel of the device being addressed 
and the memory address of the descriptor. The I/0 decsriptor. 
contains all of the information needed by GISMO_ for the 
operation. 
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An 1/0 descriptor is usuadly iocated by its "Reference Address» 
the memory address of the result descriptor field of the I/0 
descriptor. The resudit descriptor field is often referred to as 
the "RS fieild"» or. Result Status fields Alt of the descriptors 
associated with a given control wilt be tlinked together in 
memory» by setting IO-LINK to the memory address of the RS fieid 
of the next descriptore The descriptors are atso Linked in the 
reverse direction» using the I0.BACK»LINK field» to facilitate 
adding and deleting descriptors. A tink field may not be zeroes 
but a descriptor may be linked to itself. 


The Reference Address points to the RS field. Each RS field is 
twenty "four bits in tengthe The bits in the RS field have 
different meanings at different times. GISMO is most concerned 
With the setting of the bits when the I/0 is initiated. The MCPs 
are more concerned with the setting of the bits when the [/0 is 
complete. When the descriptor is ready for initiations the RS 
-field is formatted as shown in the following diagram. This fietd 
is usually referred to as the resuit status field when the 
descriptor is ready for execution or is in process and as a 
result descriptor field when the 1/0 operation is complete. 


Bits 0-1 = RS Status Bits 


00 - Ready to be Executed 

01 - i/0 Currently in Process 

10 ~ I/G Coanlete with no Exception 
11 - 1/0 Complete with Exception 


Bits 2-21 - Gismo Toggles 
MCPs may not aiter any bits in this field if 
RS Status = 01. 
Bits 12°14 ~ Port to which this 1/0 is directed. CNot used) 
Bit 15 - Iaterrupt requested on Ivo Coapletion. 
Bit 16 - High Priority interrupt requested on 1/0 
Completion. 
Bits 17719 - Port to which interrupts are to be sent upon 


I/0 Compdetion CAlways Processor Zero). 
Bits 20-23 - Channel on which I/0 is to be performed. 
The tLeftmost bit of an RS field is always set when the operation 


is complete. Consequently» storing a result descriptor locks the 
descriptor to GISMO. The MCP may lock a descriptor as wells» iif 
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the status fieid is not O11. Gismo will ontiy initiate “ready” 
descriptors» those whose status bits are equal to 00. #£=when the 
operation is initiated» GISMND sets the status bits to O01. The 
GI5MG toggles area is used by GISMO when an I[/0 is in process to 
store information which it needs concerning the operation. 


CHANNEL TABLE 


Another structure associated with peripheral management is the 
channel table» There is one channet table for each port and each 
element of the tabtle describes one channel of that port. While 
GISN0 uses the I/0 descriptor to communicate directly with the 
I/0 subsystem» the channel table is a structure for passing 
information between the MCP and GISNO. The channet table 
reflects the status of a particular channel. Certain information 
is passed to GiISMO during a “dispatch” operation and is used by 


soft I/0 in managing the execution of that operations Certain 
fields are updated before GISNO passes controt back to the MCP 
which direct the course of action the MCP wilk takee A 


programmatic description is given below? 


DEFINE CHANNEL.TABLE.DECLARATION AS # % 
DECLARE O12 DUMMY REMAPS CHANNEL.TABLE 2% 


° O02 CHANNEL.}j8U SY BOOLEAN Z 
°» O02 CHANNEL.PENDING BOOLEAN % 
F O02 CHANNEL -EXCEPTION BOOLEAN Z 
° O02 CHANNEL*»*PAUSE ‘BOOLEAN Z. 0 = TAPE» DISK» CAS 
» 02 CHANNEL.QVERRIDE BOOLEAN &% 
» O02 CHANNEL »eEXCHANGE BOOLEAN 2 
» O02 CHANNEL.OLD-MODE BOOLEAN 
°® 02 CHANNEL.INTEGRITY BOOLEAN 2% 
? 02 CHANNEL »NOeHALT BOOLEAN &% 
° 02 FILLER BIT (3) 2 . 
» 02 CHANNEL.TYPE BiT (4) 2% DEVICE TYPE FOR DUMP 
z TYPE = 0 = SERTAL CEVICE 
z TYPE = 1 = DISK 
% TYPE = 2 = TAPE 
z TYPE = 3 = CASSETTE 
» 02 CHANNEL .LAST BOOLEAN &% DELIMITS CHAN TABLE 
r O02 CHANNEL eEXCHANGESPC BIT (7) 2% 
>. O03 CHANNEL-~EXCHANGE.P BIT (3) 2% 
, 03 CHANNEL~EXCHANGE.C BIT (4) 2% 
» O02 CHANNEL «REF ADDR ADDRESS % 
a 2 


In the CHANNEL.~TABLE» BUSY is set and reset by GISMO ontye- It is 
set when the control is busy. PENDING jis aiso set and reset by 
GISMO. It is used on tape and disk devices only and it teils 
GISMG to continue Linking through the head of the queue. 
EXCEPTION is used on ali devices except tape and disk. It causes 


Bi000 MCP MANUAL 
MARK 10.0 


GISMO to inhibit dispatch operations on the channet until a prior 
exception condition has been handied by the MCP. 


PAUSE is also known as the TIMER bit» It is set by the MCP and 
it never changes. It causes GISMO to issue a dispatch to the 
channel at each 100 wmiltisecond timer intervat and is used to 
implement TEST»ANDeWATT operations on tape and disk controls. 
This is discussed in more detail tater. 


The OVERRIDE bit is used on ali devices and causes GISMO to reset 
BUSY» PENDING and EXCEPTION when a new operation is dispatched. 
It is set by the MCPs and reset by GISND. Essentially» it causes 
GISM0 to override an existing operation with a new operation. 


The EXCHANGE bit is set by the MCP and it never changese It is 
used on tape and disk controts only and it means that the 
information in EXCHANGE.»PC is vatid» that there is another 
control connected to this control by a hardware exchange. The 
OLD.MODE bit» also known as the PAUSE bit» is also set by the MCP 
and mever changes. It is set for Single-Line Controts and for 
Disk Cartridge Control One. It causes GISMS to pause for 100 
middiseconds when a tocked descriptor or a Pause I/O descriptor 
is encountered. If this bit is not set» GISMNO will stop in this 
circumstance on these controls. 


The INTEGRITY bit is set by the NCP when the channel table ontry 
is initialized. It is also used by the MCP to stop GISMO from 
linkimg on the channel. 


The TYPE field is used only by the Dump Analyzer program. It is 
necessary because the anatyzer may have no other means of 
determining this information. The REFeADDR field contains the 
address of the descriptor that is in process on this channel. [It 
is considered the head of the queue by GISM0. 


GISMOZHARDWARE INIEREACE 


The I/0 descriptor contains most of the information GISMO needs 
to accomplish an I/0 operationo In the actuat hardware 
interfaces the OP» BEGIN» ENDs DISK.~ADDRESS and ACTUAL»END fieids 
are used» The ACTUAL-~END field is twenty~four bits in length and 
immediately preceeds the RS field in each descriptor. It is not 
shown in the preceding I/0 descriptor diagram. The field is used 
by GISMO while the operation is in process to store the memory 
address of the data that is to be transferred to or from the 
memory buffer. When the. operation is complete» ACTUAL.END will 
contain the address of the next bit that data would have been 
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transferred to or from. 


Each control is able to buffer» or stores acertain amount of 
data to be transferred. The amount varies among the devices» 
For some devices» such as the card reader and tine printers it is 
a full record. For others» the size of the buffer may vary and 
each contol may contain a portion of the datas Disk controls» 
for example» are equipped with a certain number of i80~byte 
hardware buffers. The amount of data that may be contained in 
the controts and the procedures that GISM0 must follow in the 
execution of an operation are fixed when the controt is designed 
and do not change afterwarde 


CACRE CYCLES 


The hardware in the processor that is used by GISM0 is’ the 
Coamand Registere the Data Register and the Service Request 
level. The Command Register is used to send information to a 
controls the Data Register to receive from the controt and the 
Service Request Level indicates that a control needs attention 
from GISMO. 


Most transactions With the control consist of a 
Command~Activate/Response~Compiete (CA/ROD cycle. Data or 
command information is sent out to a control with a CA. Control 
information or data is returned with a RC. 


PROCESSOR 120 ZINSIRUCTZONS 

The processor instructions whch GISMO uses to accomplish an 

operation are: 

TEST STATUS 
GISMO requests and the control returns its current status 
count and the device ID. GISMO uses this information to 
decide what to do next. 

TEST & CLEAR 
This operation clears the control. 

TEST SERVICE REQUEST 


GISMO requests» and the processor returns» a mask of all 
channeis that are currently requesting services 


TERMINATE DATA 
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This operator is used to terminate data transfer when the 
media» disk and tape for examples has no fixed record size» 


TRANSFER GUT A 


Noves one or two bytes of data from memory to the control 
for output to the device. Data is sent at CA times the 
controi returns its status at RC time. 


TRANSFER OUT 8B 


Moves three bytes of data from memory to the controid for 
output to the devices 


TRANSFER IN 


Moves ones two or three bytes of data from the control to 
main memory on input operations. The data is sent at RC 
times When one or two bytes is transferreds the controi 
also sends its status 


SERVICE REQUEST 


‘The Service Request level is a toggle in the processor which is 
settable by any controt. It is OR“ed into the "Any Interrupt™ 
toggle. Fach Interpreter» prior to executing an S~oeratore will 
test the Any Interrupt toggle andes if it is set» transfer control 
to GISMO instead.j GiSM0O wit determine what caused the toggle to 
be sete In this cases it will discover that Service Request is 
raised. 


It wilt then do a TEST SERVICE REQUEST CA/RC cyclee The RC will 
return a mask of aid controls that are currentty requesting 
servicee GISMO will select the highest channel from this mask 
and begin handling that control. Conrols are usuaiiy in status 
count 211 or 18 when they raise Service Request. This status 
indicates that the controt is ready to send a Reference Address 
to GISM0. GISMG accepts the Reference Address and uses it to 
locate I/0 descriptor in memorye 


GISMO will then do a TEST STATUS CA/RC cycle to detemine what 
service the control is requestinge Once the requested service 
has been performed» and the controt no tonger is requesting 
services GISMO will again perform a TEST SERVICE REQUEST CA/RC 
cycle. It widl continue handling Service Requests from various 
controls until the TEST SERVICE REQUEST returns aid zeros» GISMO 
then returns control to the Interpreter that was interrupted. 
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SLATUS COUNTS 


The Status Count returned by a control is the primary means in 
which GISMNO determines uhat is to be done next in an 1/0 


operat ions Qperations may consist of sending the Op code = and 
file address» sending the Reference Address» receiving the 
Reference Address» sending or receiving data and receiving the 
results Various controts perform these steps in different 
orders. . 


All controls begin in Status Count 1 and return to Status Count i 
after Status Count 23. Each Status vatue has a particudar 
meanings Some counts always appear in series togethere- Ata 
controts begin an operation by going through Status Counts 1 
through 6. A simplified table of the allowable Status Count 
transitions is shown in the table below.’ 


To send each of the twenty-four bit fieids OPs>s DISK.ADDRESS and 
Reference Address» three TRANSFER OUT operations are used» each 
CAJRCO sending one bytee ‘For each TRANSFER OUT» the Status 
Counter advances by onee Simidarily» to receive either the Resuit 
Descriptor or the Reference Address» three TRANSFER IN operations 
are used» each CA/RC receiving one byte. 
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Status Count Meaning 

0 Control Net Present 
1 Cleared CInitiat) State 

le 2» 3 Ready to Receive OP» Bytes l» 2 and 3 

4» Se 6 Ready to Receive DISK ADDRESS» Bytes il» 2» 3 

Te 8 9 Ready to Receive Reference Address» Bytes lI» 2» 3 
10. Busy COperation in process). From 10» Controis 


usually go to Status 14 or 18 and raise 
Service Requeste 


lly 12> 13 Ready to Send Reference Address» Bytes ls 2» 3. 
14 Ready to Receive Data Coutput) 
15 Ready to Send Data Cinputd 
16 End of Hardware Buffer - Ready to Send or Receive 


Last Bytee Nore Buffers Remaine 
17 End of Hardware Buffer and Last Buffer. 


185 19» 20 Ready to Send Reference Address» Bytes ll» 2» 3-4 
Implies that a Result Descriptor is to Fottow. 


2i» 22» 23 Ready to Send Result Descriptors Bytes 1» 2» 3. 


Table XX = Typical Control Status Counts and their Meaning 
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DATA TRANSEERS 


GISMO0 transfers data to and from the control in one or amore 
jterationss each iteration widl involve onty one controt buffer. 
For some devices» there is only one buffer and this buffer will 
always contain the full physical record. GISMO will only perfora 
data transfer once per I/0 operation for these controls. Other 
controls have physical records of undefined lengths for these 
controls» there are usuadly muttiple buffers of fixed length in 
the controt and each iteration of GISMD wilt fill or empty one of 
these buffers. 


Whenever Service Request is raised and GISMO is invoked» the 
requesting control wilt first send the reference address. GISMO 
will then test the controt"*s status.» If the controt is in Status 
14 or 15% GIS5M0 will begin data transfer. For each operations 
data transfer will continue until either the control's buffer is 
empty or the END address of the I/0 descriptor is reached. In 
the first case» the control will have gone to Status 7 after the 
last data character €s). GISMO wiidl test its status» see that it 
is in Status 7 and send it the Reference Address» thus completing 
the iteration. In the latter case» on most controls» GISNO wilt 
send it a TERMINATE command. Some controls require data transfer 
to continue untif the end of the control's buffer. On input» 
GISMO will accept the remaining data from these controls but will. 
not store it in memory. On output GISMO will send blanks to 
these controlse- 


Data is always transferred to a control in oner two or three byte 
portions. Most “Seriai*" devices» such as printers and card 
devices» use one byte transfers- This data transfer is performed 
from a toop within GISNO which consists of a CA/RC cycle» 
transferring one data bytes until the control's buffer is fudl or 
the END address is reached. A buffer full condition is detected 
by the control sending or receiving: the tast data byte in Status 
Count 16 or 17. 


Many disk and tape controls transfer data two bytes per CA/RC. 
Disk input and output is always terminated by GISMO when the END 
address is reached» possibly in the tast of multiple disk 
sectorse When the record length is an odd number» GISM0 will 
normatize the last byte as required.» Qn output operations» the 
controd wilt pad the remainder of the tast buffer Cand hence 
sector) with zerose 


Tape outputs possibly in the Last of multiple buffers» is also 
terminated by GISMG when the END addrass is reached. When the 
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Physical record size is an odd number of characters» GISMO wild 
normalize the last byte for the Last CA/RC cycte. It will send a 
TERMINATE command» foitowed by a special command which wilt 
indicate “odd character count? to tell the controt that the tast 
data transfer consisted of one byte only. Tape input operations 
wild terminate either when the END address is reached or when the 
end of the physical record is encountered» which may be in the 
last of muitipie buffers. If the end of the physicai record 
occurs and the dength of the record is an odd number of 
characterse the control will set a flag in the RC portion of the 
last CA/RC cycie.e. GISMO witli then normalize the last byte of the 
record. 


Ald disk pack controls» the 5N head-perstrack control and ait 
phasewencoded tape controls use three byte data transfers. In 
this case only» an exception is made to the generai crude that aii 
transactions involve one CA and one RC. On these controls» one 
- CA may be followed by one or more RCs. This is accomplished as 
foitows. 


Prior to entering the transfer loop» on input» GISMD will use a 
special CA/RC cycle to ask the control how many butes it has to 
sende It wilt then initiate the transfer toop with a CA and 
continue it with as many RCs as are required» receiving 
twenty-four bits of data on each RC.j For output» GISMO will teil 
the control how many bytes it has to send» It witl then initiate 
the transfer tLoop with a CA command of TRANSFER OUT Bs = and 
continue it with as many RCs as are required» sending the data 
out with the RC. 


I7Q CHAINING 


The I/D subsystem of the B1000 system does not use queues for I/0 
operationss Using the facilities presented in the preceding» it 
connects alt I/0 descriptors that are directed to the same 
controls or group of controls connected by an exchange» in oa 
circular chaine This eliminates the necessity of an 1/0 compiete 
interrupt being directed to the NCP» provided the producer of I/0 
requests» most often a user programs does not produce the 
requests faster than they can be satisfied. In other words» if 
the I/70 subsystem is compieting operations before they are 
actualiy required by the usere then the user will never need to 
wait on. the completion of an I/O request and the MCP witt never 
haye to suspend the program waiting for such a completion. 


Even if this isn"t the case» if the user program is forced to 
wait upon the comptetion of his I/0 requests» the amount of 
processing that must be done to accomplish the suspension and to 
reanstate the program upon completion is minimized using 
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chaining» The processing is iimited to only that -which is 
concerned with program execution and no processing is required to 
tell the I/0 subsystem what it should do nexte This information 
is already contained in the 1/0 descriptor. 


For alt devices except tape and disks then» the MCP constructs a 
circular chain of descriptors in semory. GISMO executes the 
requested operations in turne as each descriptor is uniocked by 
the MCP. Upon encountering a locked descriptor» GISM0 simply 
pauses or stops until the descriptor is untccked. This wild 
occur when the user program next executes an I/C request or when 
the file is closed for any reason. If the program must wait upon 
an. operations an I/0 complete interrupt is requested» using the 
appropriate bit in the RS fields and the program is suspended 
pending the occurrence of the interrupt. 


DISK I1Z0 CHAINING 


The disk I/0 subsystem operates somewhat differently from the 
operation just described. Since each disk I/0 descriptor 
contains a disk address fieltd» it ais not necesary for the 
operations to execute in any particular ordere Various means are 
provided in the software to prevent any contention problems that 
might arise. It may be noted that these same means are necessary 
on I/G subsystems which utilize queueing instead of chaining» 


Ali I/0 descriptors for aii disk controls that are connected to 
the system are connected in the same chaine If the system is 
equipped with more than one controls then each Channet Table 
entry will point to the head of the chaine If GISMO encounters a 
descriptor which is not ready for execution or which is already 
in process» specified by the first two bits of the RS field being 
set to anything other than 005° it does not stop or pause but 


continues to the next descriptor in the chain. Also» if an 
exception condition occurs» GISMO does not stop or pause as it 
‘does on other controls. Both of these actions are specified by 


the CHANNEL.~NO.HALT bit in the Channel Tabtee 


Since GISMO continues Linking in) both of the cases sentioned 
above» it must know when it has examined ald of the descriptors 
in the chaine When it has examined allt of the descriptors» it 
must stop to free the processor for other execution. To 
accomplish this» the REFeADDR fietd in the Channel Table is used 
to mark the beginning of the chain. When a disk operation is 
dispatched by the NCP» the reference address passed by the 
dispatch is discarded and the REF.ADDR fieid is used instead. 
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In order to operate properly with dispatch operations occurring 
in an order different from the order of the descriptor tink 
fields» GiISMO must be able to override stopping when it has been 
through the entire chain oncee For examptes if descriptors A» B» 
and C are present in the chain and if 8 is dispatched» GISMO will 
link to and initiate B. If» during the time that B is in 
process» A is dispatched» GISMO must Link past C and the REFeADDR 
field and find and initiate A. 


To accomplish this» the PENDING bit in the Channel Tabie is used. 
This bit ais set by a dispatch operation and reset by GISMO. If 
GISMO arrives at the descriptor addressed by the REF.ADDR' field 
and if the PENDING bit is set» it does not stop but resets 
PENDING and continues Linkinge If PENDING is already reset at 
this pointe then GISMO stops. 


Since ali descriptors for ali disk controls are maintained in the 
same chain» GISMO must be able to recognize descriptors which are 
addressed to controls different from the one it is handling. 
This is accomplished using the I0-CHANNEL-RS field of the 1/0 
descriptor. Upon encountering an unlocked I/0 descriptors GISMD 
compares this field to the channel it is executing upon and iif 
the two are not equale it does not mark the descriptor in process 
but cantinues Linking. 


DISK 120 OVERLAPPED SEEKS 


When an I/0 operation is initiated on a moveable arm disk device 
and the arm is presently positioned to a cylinder different from 
the one specified in the descriptors it is necessary to 
reposition the arm to the proper cytinder. This operation is 
known as a “"seek*» Gn the 81000 system» all seek operations are 
implicits there is no explicit Seek operation in the hardware. 
The MCPs initiate disk I/0 operations without regard for the 
current arm position and» if arm movement is required» it is 
accomplished by GISMO» the control and the device without the 
MCP*s participatione The MCP does not know that a seek is being 
performed or required. 


On this systems aid seek operations are *"overtapped"» This means 
that the arm of any given drive may be in motion simultaneously 
With the arm of any other drive(s). Aisor the control may be 
performing data transfer oor any other operation while the arms 
are in motions . 


This is accomplished by the control returning a result descriptor 
With Bit 1725 [OQ.RESULT.~BIT~172 set to zeros Esssentiaily» this 
informs GISMO that some speciat action is necessary and that 
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GISMO should not store the result descriptor in memory. In this 
particular caser the control also informs GI5M0 that the selected 
drive is now seeking. GISMO will initiate no further operations 
upon that drive until informed» by the hardwares that the seek 
operation has completed. 
\ 

DCC-2 CCartridged and ali disk pack controls notify GISMO that a 
seek operation has completed by raising Service Request while in 
Status Count I. GISNGO wild again send the descriptor to the 
control and this time» after any required latency period» data 
transfer witli occur. DCC-1 does not notify GISMO when a seek 
operation has completed but must be “podled"™ periodically by 
GISMD~ The pause time period for DCC-l» the time between the 
poll operations» is two mittliseconds.e 


The Disk Subsystem Controilter (DSC) offerred on GEM processors 
introduces some exceptions to the statements above. These 
exceptions will be defined in a subsequent version of the 
specification.e 


TAPE 120 CHAZNING 


The chaining of I/0 descriptors for magnetic tape controls is 
perhaps the most complex of the three basic types. The 
complexity is caused by the fact that tape 1/0 descriptors 
directed to each separate tape unit must be executed in togical 
sequence and there may be severad such units attached to the same 
controlls de. It doesn*t matter which unit GISMG addresses next 
but the descriptor that is used to address the unit must be the 
next dogical descriptor in the *"subchain”™ for that unit. It is 
therefore necessary to break the channet chain into subchains» 
with one subchain for each physical unit» and to implementa 
means of remembering the next togicat descriptor that must be 
used within each subchain. 


Both of these requirements are satisfied by the Lock descriptor. 
Lock is a pseudo I/0 operation which is handled completaly by 
GISMO and actually causes no physical 1/0 operations. It aiso 
serves. aS a means of resolving contention problems between the 
MCPs and GISMO and between two or more tape controls which are 
attached to the same units by an exchange. Lock operates as 
described betow. 


The MCP» when the system is Ciear/Started» constructs a tape 
chain. with one Lock descriptor for each unit connected to the 
system. The ACTUAL-END fieid of a Lock descriptor is not used 
and the LINK field wilt contain the memory address of the next 
Lock descriptor. The BEGIN and END address fields of the Lock 
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descriptor will contain the address of the TEST»AND WAIT I/0 
descriptor that the MCP uses to monitor the status of each unit. 
This is discussed in a dater paragraph» 


When a file is opened on a tape unite the MCP changes the BEGIN 
and END address fields in the Lock descriptor. The MCP now 
constructs a subchain for the unit which will consist of one I/0 
descriptor for each buffer requested by the user. The BEGIN and 
END addresses of the Lock descriptor wilt be set to the memory 
address of the first physical 1/0 descriptor in the subchain. and 
the TEST.AND.WAIT descriptor wilt be removed from the subchain. 
The BEGIN address field will not be altered from this point untiad = 
the file is Closed. The END address wiil be modified by GISMO 
each time it executes an operation in the subchaine In effect» 
The END address field is used to remember the next Logical 
operation that is to be performed on the units. 


The LINK fields in each I/0 descriptor in the subchain wilt all 
address the next physical descriptor in the subchain» as they do 
for ail other controlse An exception to this is the tast 
physical descriptor in the subchain. The LINK field of this 
descriptor will contain the address of the Lock descriptor for 
that unite This prevent one unit from monopolizing the entire 
control; it insures that GISMO will periodicaily determine if 
there is anything to be done on the other units. 


The REF~ADDR field of the Channel Tabie entry for a tape chain 
wild contain the address of the first Lock descriptor in the 
chain. Gismoe upon receiving a Dispatch for a tape control» will 
discard the Reference Address passsed and start at the address 
provided by the REFeADDR field. GISMO first atteapts to tock the 
Lock descriptor by swapping O01 into the first two bits of the RS 
field. If successful» it fetches the address in the END field of 
the Lock descriptor and proceeds to that address. If this 
descriptor is untlockeds it begins the operation specified» If 
not» it returns to the Lock descriptor and stores the address» 
which it previousiy fetched from the END address fieid back into 
the END address field. 


Assume now that the descriptor at the address fetched from the 
END field of the Lock descriptor was unlockede GISMOG begins this 
operation and» assuming that the operation cannot be compieted 
without some intermediate Service Requests» returns to the Lock 
descriptor and continues tinking through the chain. Eventuatty» 
the controd will raise Service Request and reference’ the 
initiated descriptors. Upon completion of that descriptor» GISMO 
wilt store aresult and fetch the LINK field of the descriptor. 
It wilt then proceed to the new descriptor and again check to see 
if it is tocked. If it is» GISMO returns to the Lock descriptor 
for the unit and stores the new address in the END address field. 
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The new descriptor now becomes the next Logicat descriptor to be 
executed on that units In this mannere GISMO effectively 
maintains a togical sequence of operations that are to be 
performed on any tape unit. 


It may be noticed from the foregoing that there is no possibility 
of conflict for a unit between two or more controls connected by) 
an exchanges since GISMGQ first attempts to lock the Lock 
descriptor before proceeding down a subchain.» -Similarty» the MCP 
must tock the subchain before altering. any. descriptor in the 
subchain. 


MONITORING OF PERTPHERAL STAIUS 


The MCP attempts to monitor the status of all peripheral devices 
that are attached to the system. To do this» it must remember 
the status of each device and aaintain a certain amount of 
information about each. The major portion of the information 
about alt of the devices connected is maintained in the I/0 
Assignment Tabie CIGAT). 


122 ASSIGNMENT TABLE 


The I/O Assignment Tabie CIOAT) allows the MCP to keep track of 
ald peripheral units except the system*s SPO and those devices 
associated with data communication. Each unit is identified by 
ports channel» and unit numbers as weil as by a symbolic name. 
Various fields reflect the status of the untt Ce.ger AVAILABLE » 
SAVED» REWINDINGs LOCKED). A programmatic description is given 
below? 


DEFINE IOAT»SIZE AS #512#3 


DEFINE LOAT»DECLARATION AS # *GLOBAL Ioat 
DECLARE 12 DUMMY REMAPS IDAT+ 
02 UNIT.»ZINITIAL BIT C66)» Z 
03 UNI T»HDWR BIT (6)» 
03 UNI T»PCD BIT €12)»5 Zz 
04 UNIT~PORT.CHANNEL BIT (7)» &% 
05 UNITPORT BIT C3)» 2% 
05 UNIT~CHANNEL BIT C4)» & 
04 FILLER BODLEAN» % 
04 UNITUNIT BIT C4)e 2 
03 UNIT Te NAME CHAR (€6)>» 
02 UNIT.»LABEL.ADDRESS . DSKeADR » 
03 FILLER | BIT €12)>» 
03 UNIT T»PACK.~INFO ADDRESS» 
02 UNIT.RS ADDRESS»% USER LIMIT REGISTER 
02 UNITFLAGS BITC36)» 
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03 


02 


02 
02 
02 


03 UNIT»TAPE*XCH 
03 UNIT-NO»jTRANS~TBLE BOOLEAN» ZPC=5 
UNITOFFLINE.YET~INUSE 


03 
03 


UNIT»AUDIT 
UNT T.RESERVED.»BY.AB 


03 UNIT~LABEL~OP 


UNIT.DREIVE.~TYPE 
Z VALUE DCCis2/3 
x 0 532X203 
z 1 32X406 
4 2 64X203 
z 3 64X406 
z 4 N/A 
F 4 5 N/A 
a 6 N/A 
F 4 rf N/A 
UNTT»STATUS 
UNIT.»~TO-BE»POWERED OFF 
FILLER 
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UNITeAVAILABLE BOOLE AN» 
UNIT»eAVAILABLE INPUT BOOLEAN» 
UNIT.AVAILABLE OUTPUT BOOLEAN» 
UNI TeHAIT»FOR»NOTe-READY BOOLEAN» 
UNIT T2TEST.AND.WATT BOOLEAN» 
UNI T.»SAVED BOOLEAN» 
UNITs#REWINDING BOOLEAN» 
UNIT»EOF»SENSED BOOLE AN» 
UNTT.LOCKED BOOLEAN» 
UNI T»LABEL»SENSED BOOLEAN» 
UNIT»PRINTjBACKUP BOOLE AN» 
UNIT T.PURGE BOOLEAN» 
UNI T»LOCKeATeTERM BOOLE AN» 
UNIT T.TO.-BE-SAVED BOOLE AN» 
UNIT.FLUSH BOOLE AN »% 
UNTT~TAPEF BOOLE AN» 
UNI T.£DISKF BOOLEAN» 
UNIT T»jSTOPPED BOOLEAN» 
UNI T»TRANSLATE BOOLE AN» 
UNI T»CTRL-CARD.USING BOOLEAN» 
UNIT»REMOTE.}J0B BOOLE AN» 
UNI T»CLOSED BOOLE AN» 
UNIT.CLEARED BOOLEAN» 
UNTTeMULTIFILE BOOLE AN» 
UNIT »EOT BOOLE AN» 
UNITT.TAPE~FILE-STATUS BITC33+2z 
z 
4 
% 
x 
z 
x 


“VIE WN eH Oo 


FLUSH TO EOF 


NOT RELEVANTC_ANST)D 
BOVIBEG OF VOLUME 
BOFCBEG OF FILE) 
EQVCEND OF VOLUME) 
EQFCEND OF FILE) 
PFBCPROCESS FILE BLK 
UNDEFINED 


Hu dow ue ie ii 


BOGLE AN»? FOR MIS“MATCHED UNITS 


BOOLEAN»2FOR ASSIGNED UNITS. 


BOOLE AN» 


BOOLEAN 2% 


% DNS AUDIT TAPE 
AUTG BACKUP 6.1 


BIT(3)2Z% O=9OO0EOOXaS ODD TRANS 
% 1=200C00X@ 00D NO TRANS 
Z 2=2300600X2 EVEN TRANS 
% 3=300400X2 EVEN NO TRANS 


BIT(&)>zZ DISK ONLY 


DPC1/2 DFCI DFC3 
N/A N/A N/A 
215 SYS.MEM 5N 
225 N/A N/A 
N/A 163 N/A 
207 10-4 N/A 
205 LA-3 N/A 
206 LA-4 N/A 
N/A N/A N/A 

BIT (15) 
BOOLEAN» 
BITC? )» 
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02 UNIT.JOB.NUMBER BITC16)> 
02 UNIT.»FIB.ADDRESS ADDRESS» 
O02 UNIT»LABEL»TYPE _ BIT €2)» 

x 0 = OMITTED 

z 1 = BURROUGHS 

z 2 = USASI 

x 3 = INSTALLATION 
02 UNIT.TRANS»T8LE.1D BIT(8)» ZPC-5 TRAIN ID 
02 FILLER. WORD» % PLEASE DO NOT DISTURB 
02  UNIT.STEST.DESC BIT CDESCRIPTOR.SIZE)3 


as x DELIMIT ToOAT DEF INE 


The entire IGAT is constructed by the MCP when the system is 
Cilear/Started- Ouring the Clear/Start operations the MCP directs 
a Test descriptor to each of the controls that are connected to 
the systems When it discovers a controt that may have more than 
one unit connected to it» it sends a Test descriptor to each 
possible unit and makes one entry in the IGAT for each unit that 
is connected. 


The UNIT.HDWR fieid in the IGAT witt contain the hardware 
Sdentifier returned by the test descriptor. The fotioning is a 
dist of hardware types and pseudo"types that are supported by the 
MCP. Pseudo~types are used in the device assignment process to 
indicate generic types» such as "any magnetic tape device” which 
would include sevenwtrack»s nine~track»s phase encoded» NRZ and so 
forthe ; 
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DEVICE FILE STMT HDWR TYPE 
Reserved 00 
80 coi READER.~PUNCH»APRINTER DATA»RECORDER.j80 01 
80 col CARD PUNCH CARD»PUNCH 02 
Reserved 03 
FOCe1 ; 04 
96 col READER PUNCH PRINTER READER-PUNCH.PRINTER 05 
PAPER TAPE READER PAPER.» TAPE READER 06 
PAPER TAPE READER~1 PAPER» TAPE *READER 07 
PRINTER PRINTER 08 
READER SORTER~2 READER» SORTERe2Z 09 
READER SORTER READER.~SORTER 10 
DISK FILE Any head per track) DISK.FILE il 
DFC=-1 DISKeFILE.1 12 
DCC-2 DISK.~CARTRIOGE 13 
DcC@-1 DISK»CARTRIDGE 14 
DPC=1 DISK»PACK.10 15 
DISK PACK CDCC-1»> DCC-2- DPC-1) DISK.PACK — 16 
DISK CAny disk) DISK iv 
DFC-3 {5-N) DISK»FILE. 3 18 
96 col READER READER.~}96 19 
PAPER TAPE PUNCH PAPER.» TAPE PUNCH 29 
80 colt CARD READER CARD»READER 21 
SPO-1 22 
SP0"2 CRT SPo 23 
TAPE 9 TRK NRZ TAPE.9 24 
TAPE 7 TRK NRZ TAPEs7 25 
TAPE PE €9 TRK) TAPE.PE 26 
TAPE CAny taped TAPE 27 
TAPE»9 CAny 9 TRK tape) TAPE.9 28 
Reserved 7 29 
CASSETTE CASSETTE 30 
LPC=5 PC.5 31 
QUEUE FILE QUEUE 62 
REMOTE FILE REMOTE 63 


Table 3e.x ~ Hardware types supported by MCP 
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In the table above» the File Statement column (FILE SIYMT) is for 
use in the MCP*s FILE Controt Card and is explained in the 
software Operational Guide. Generic hardware type numbers are 
not stored in the IOAT. Rathers the actual identifiers returned 
by the hardware are usede 


UNZT MNEMONICS 


Unit mnemonics are also assigned by the NCP during the 
Clear/Start process. These mnemonics altow the operator and the 
MCP to identify devices uniquediy.e The tabde below lists the form 
of the snemonic that will be assigned to the various types of 
devices» 


Card Reader CRx 
Card Punch CPx 
Data Recorders CDBx 
Printers LPx 
Tape Units MTx 
Disk Chead-per~track) none 
Disk Pack DPx 
Disk Cartridge | DC x 
Paper Tape Readers PRx 
Paper Tape Punches PPx 
Reader~Sorters RSx 
Cassettes CS*x 
Flexi~Disk FDx 


Ald units will be assigned a threewcharacter anemonic which 
begins with the first two letters Listed in the tabte above. The 
third character wilt be unique to the unit. The first unit of 
that type encountered by the MCP during the Clear/Start operation 
is assigned the tetter “A> the second “"B" and so _ forth. 
Assignment proceeds adphabeticatiy and the mnemonic assigned does 
not change unless the system configuration changes. 


The assigned unit mnemonic is stored in the IOAT tn the UNITNAME 
field. The entire IOQAT is maintained in memory. To minimize 
storage requirements» some information which relates to the unit 
is not stored in the I0AT but is maintained on disk. File 
Identifiers and any other information which is seldom used by the 
MCP are stored in an INTERNAL»~LABEL fietd on disk. The disk 
address of this field is maintained in the IGAT in the 
UNIT»LABEL»*ADDRESS field. Information in this field is typically 
updated by the STATUS procedure in the MCP. 


The STATUS procedure is executed whenever the Ready status of an 
unassigned device changes» The MCP is. made aware of a status 
change by TESTeANDeWAITT I/0 operators» These operators do not 
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truly wait on a unit status change but this function is emulated 


TESTsANDeWAIT 1/70 OPERATORS 


The MCP must know when a unit goes from a Not Ready condition to 
a Ready condition so that it can read the label on the media and 
update the INTERNAL.~LABEL information on diske It must know when 
a unit changes from Ready to Not Ready so that it can mark the 
unit unavailabie and initiate a TEST.»AND~WAIT.FOReREADY on the 
units TESTe«AND»AWAIT operations altow the specification of 
certain conditions for completion» such as Test and Wait for 
Ready » Not Ready» Ready to Transmit» Ready to Receive and so 
forthe GI5M0 will not consider the operation complete untess the 
specified conditions are met. 


On disk and tape controltss which atlow more than one untt per 
controls we cannot tie up the entire control with a Test and Wait 
operation to one unite For DOCC=-2s alt disk pack and aii tape 
controls» the PAUSE bit in the Channel Table is used to implement 
a periodic test of atl such unitse At each 100 millisecond timer 
intervals» GISMOD searches through the Channel Tabte Looking for 
entries with this bit set to zero. When such an entry is founds 
GISMOD initiates that chain at the address specified by REF..ADDR» 
also in the Channel Table. During this executions GISM0O wild 
initiate aii Test operations encountered in the chains If the 
conditions for completion specified in the operator have been 
met» GISMO wid store the resuit descriptor returned by the 
operation and queue an interrupt for the MCPs the MCP always 
requests an interrupt in Test and Wait descriptors. 


The MCP aiso sets the type field of this I/0 descriptor» 
I0.MCP.IO» to a value which indicates “Status Change™. In the 
MCP%s I/70 Comptete procedure» which is invoked only when an 
interrupt is returned from an I/0 operation» the value stored in 
I0.MCP..IO0 widil cause invocation of the MCP*s STATUS Procedure. 


STATUS PROCEDURE 


As mentioned previousiy»s the STATUS Procedure is esxecuted onty 
when the status of an unassigned peripheral changes» If a 
peripheral is being used by a program and if it goes to a Not 
Ready conditions the situation is handted by the I/0 Error 
Procedures When an assigned peripheral goes from Not Ready to 
Ready» no action is required by the MCP since the Test and Wait 
descriptor executed in this case wilt have a LINK field set to 
the next Logical operation to be performed on the device. 
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Peripheral devices which are capable of input operations usually 
have labels written on the mediae The MCP is equipped to 
recognize severat different tlabetl formats on disk and tape 
devices and it expects to read controi instructions from aii card 
devices which have input capabilities» Controt instructions are 
discussed in the Software Qperational Guide and in Product 
Specification 2219 O144» MCP Control Syntax and wiil not be 
discussed heres Essentiaily» when a card device becomes Ready 
for input purposess the Status Procedure reads the first card and 
control is passed to the Controt Card Procedure. 


On disk and tape devicess when a unit becomes Readys the Status 
Procedure attempts to read a tabel from the media. The following 
is a description of the various Label formats» on disk and tape 
devicesp the NCP is capabie of recognizing. 


DISé IDENTIFICATION = £ACK LABELS 


Every disk pack» disk cartridge» or head-per-track sub-system is 
identified by a standard "ANSI® pack lLabei. This pack tLabel» 
written in EBCDIC (8 bit coder is two pack sectors tong (360 
bytes)» and occupies the first two sectors on a pack»s LeEoe 
cylinder 0» track O» sectors 0 and le Sector 0 contains pack 
identification information and sector 1 is reserved for future 
implementation of pack security. procedures. A programmatic 
description is given below: 


DEFINE PACKeLABEL»DECLARATION AS #2 
DECLARE O01 DUMMY REMAPS PACK.LABEL2Z 


° 02 PL-VOL1i- CHAR 4) 2% “"VOL1" ; 

» 02 PLeSERTAL~NO CHAR (6) 2% SERIAL (CAN) NUMBER 

” O02 PL. ACCESS.CODE CHAR (1) 2% ACCESS CODE 

Fd 02 PL.ID CHAR C17) % PACK ID 

» 03 PL»eNAME CHAR (10) % . 

» 03 FILLER CHAR (7) % 

r OZ PLeSYSTEMe~INTERCHANGE CHAR (2) 2% SYSTEM INTERCHANGE/CODE 
% 00 = INTERCHANGE 
% i7 = 81000 INTERNAL 
% 35 = 83500 INTERNAL 
% ETC» ET» ETC 
» O02 PLeCODE CHAR (13 2 PACK CODE 00 = SCRATCH 
p 02 FILLER CHAR (6) 2% 
» O02 PLe-OWNER»ID CHAR (14) 2% 
, 02 PL»TYPE CHAR C1) 2% "R™ = RESTRICTED PACK 
x "yu" = USER PACK 
% “S" = SYSTEMsPACK 
» 02 PLeCONTINUE CHAR €1) 2&% CONTINUATION FLAG "C” 
» O02 FILLER CHAR (26) 2% 
” OZ PLeINT CHAR €1) 2% 
° 02 PL.~VOL2 CHAR (4) & “VOL2" 
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» O02 PLeDATEsINITIALIZED CHAR (5) 2% 
» O02 PL~INIT.SYSTEM CHAR (6) % INITIALIZING SYSTEM 
» O02 PLoDISK.~DIRECTORY CHAR (8) 2% DIRECTORY ADDRESS 
» 02 PLeMASTER.AWAIL CHAR (8) % MASTER AVAILABLE TABLE 
» 02 PLaDISKsAVAILABLE CHAR (8). x WORKING AVAILABLE TABLE 
» 02 PL»INTEGRITY CHAR (1) % 0 = NORMAL 

% 1 = RECOVERY REQUIRED 

» 02 PLeERRORsCOUNT CHAR (6) 2% 
» 02 PL.SECTORS-XD CHAR (6) % REMOVED SECTORS 
» 02 PL»TENP.TABLE CHAR (8) % TEMP TABLE LINK. 
» 02 PLePCD CHAR (3) % LAST PORT» CHAN» DRIVE 
» 02 PL.ASSTGNED.10.8PS CHAR (6) x BASE PACK SERIAL NUMBER 


In the case of disk devices» additional informations beyond that 
which can be stored in the IGAT» is required by the MCP for 
proper operation» The STATUS Procedure and others maintain this 
information in a reserved area in memory known as the Pack 
Information Table CPACK.~INFO). 


PACK JNEQRMAITZON TABLE 


The pack information table is an MCP maintained tinked Aist of 
ali user disk packs and cartridges currently on Lines It 
contains such inforration as the name» serial number» hardware 
unites nuaber of users» and addresses of the disk directory» 
available table» and temporary table.» This structure atlows a 
pack or cartridge to be externality referenced by name. A 
programmatic description is given betow: 


DEFINE PACK»INFO.~DECLARATION AS #% 
DECLARE 01 DUMMY REMAPS PACK.INFO> 


02 PeNAME NANE» 
O02 P»SERIAL~NO WORD» 
O02 P»DISK-DIRECTORY D3K.ADR» 
02 P.DISKeAVAILABLE DSKs ADR» 
02 P»TEMP.TABLE DSK»ADRe 
02 PUNIT.~NANE CHAR (6)» 
02 P»PCD BIT C12)» 
03 P»PORT»CHAN BIT (7)» 
03 FILLER BIT Cid» 
03 P.»DRIVE.NO BIT C4)» 
02 PeNDe USERS BIT (8)» 
O02 P»eNOMPF USERS BIT (B)» 
02 P.TOeBE»POWERED.»DOWN BOGLEAN> 
O02 PeRESTRICTED BIT (3)»5 % 0 = SYSTEM RESOURCE PACK 
Z% 1 = RESTRICTED 
% 2 = UNRESTRICTED USER 
2% 3 = INTERCHANGE 
02 PeCONTINUE BOOLEAN» Z% 1 = CONTINUATION PACK 
02 P»SCRATCH BOOLEAN» 2% 1 = SCRATCH PACK 
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02 PeFULL BOOLEAN» % 1 = NG MORE AVL DISK 
02 PeXC BOOLEAN» ZPACK HAS UNDERGONE XC. 
02 PeASSIGNED.j10.BPS WORD» % ASSIGNED TO BASE PACK 2 
O02 P»eBACKeLINK ADDRESS» 
O02 PoaLINK ADDRESS 


Bez 
TAPE LABELLING» INITZALIZATION AND PURGING 


MCP II includes the capability to create and recognize’ two 
different forms of magnetic tape tabelis. The standard tabel 
format for the B1000 system wilt conform to that specified in the 
pubdication entitled “The American Nationad Standard Magnetic 
Tape Labels for Information Exchange™ which is dated 1969 and 
published by the American National Standards Institute» Inc. 
CANSIT). These tabets are commonty known as “ANSII» Version 1” 
labels. It should be noted that "standard iabei format™ for the 
system means that any program which requests standard tabels in 
its file deciaration will cause ANSII tabets ta be written when 
the file is assigned to magnetic tape» and the file is opened 
output» Users are allowed to create the tabel in ASCII if they 
s0 desire. 


ANSII tabels as implemented on the B1000 system contain several 
deviations from the standard as presented by the ANSII documentse 
The deviations are necessary in order to insure that we are 
compatible with the B6700 systeas. The most noteworthy deviation 
is the recording mode of the tabet itself? it is written in 
EBCDIC character code unless ASCII is specifically requested via 
the *SN" command. 


ANSII label formats» as implementeds consists of three physical 
blocks on the tapes followed by a tape mark. The first of the 
three blocks is known as the Volume Header. A programmatic 
description is presented betow. 


O01 VOLUME.HEADER 


02 FILLER CHARACTERC4) 
ZThis field wilt always contain “"VOLi" 

02 VOLUME.ID CHARACTERC6) 

O2 ACCESSABILITY CHARACTER(C 1) 


ZThis field is not used by the B1000 
O02 RFS This field is reserved in the ANSII Standard. It is 
Xbeing used as follows by the B1000 and the 86700. 

03 \MULTI.FILE.ID CHARACTERC1I7) 
% "0" if there is no MFID 
% “X0O" if Scratch 
% “BACKUP™ if Backup 

03 SYS.SYMBOL CHARACTERC2) 


3-26 


Bi000 MCP MANUAL 
MARK 10.90 


X% Witl contain "17" if created on £81000 


03 TAPE.TYPE CHARACTERC1) 
% 0 = Scratch 
% 1 = User 
2 2 = Backup 
% 3 = Library 
03 FILLER CHARACTER{6) 
02 OQWNER.»jID CHARACTER(14) 
% This field is not currently usable on the B1000 system 
02 FILLER CHARACTER(28) 
O2 VERSION CHARACTERCL) 
% Widi contain "1" until such time as the label format is 
% changed . 


The second of the three physical biocks is known as “Header One". 
The format is also used for Endeof"File and End-of-Volumes A 
programmatic description is given below. 


OL HEADER1.DECLARATION 


02 FILLER, CHARACTERC4) 
X% May contain “HRDI"*» "EOFI"» or "E€0Vi" 
O02 FILE.I1ID CHARACTERC17) 
O2 FILE-SET2ID CHARACTERC6) 


% This field will contain the first six characters from 
%Z the MFID field in the VOL1I block 


02 FILE»SECTION.ND CHARACTERC4) 

% Used for Reet nusber by 86700 and 81000 
02 FILE»SEQ-ND CHARACTERC4) 

% Ordinat number of the file within a Muiti-Fite 
02 GENERATION.NO CHARACTERC4) Z% Unused 
O02 GENERATION.VERSIONeNG CHARACTERC2). % Unused 
O2 CREATION.DATE CHARACTER(C6) 2% bYYDDD 
02 EXPIRATION-DATE CHARACTERCE) Z% bYYCDD 
O02 ACCESSABILITY CHARACTERC1) ZX Unused 
02 BLOCK.~COUNT CHARACTERC6) 

% Zero if this is a Header.One block 
02 SYSTEM.~CODE CHARACTER(13) Z% ™B1700" 


02 FILLER CHARACTERC7) 


The third physical block is known as “Header Two". It is aiso 
used at Endwof*Fite and End-eof-Volume. Its format is shown 
befow? 


01 HEADER2 DECLARATION 


02 FILLER CHARACTERC4) 

% Nay contain “"HDR2"%>» "EGF2"> or *EOV2™ 
02 RECORD»FORMAT CHARACTERC13 

% F = Fixed 

% VW = Variable 


x 3% Spanned CNot yet implemented by any Burroughs system) 
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% UV = Undefined 
02 BLOCK.LENGTH CHARACTERC5) 
O2 RECORD.«LENGTH CHARACTER(5) 
02 RESVY.~SYSTEMs USE CHARACTERC35) 
03 DENSITY CHARACTERC1) 
%0= > 800 
% 1 = > 556 
% 2= > 200 
X 3 = >» 1600 | 
03 SENTINAL CHARACTERC1) Z Unused 
03 PARITY CHARACTERC1) 
% 0 = Even> 1 = Odd 
03 EXT.~FORS CHARACTERC1) 
xX 0 = Unspecified 
% 1 = Binary 
x 2 = ASCII 
X 3 = BCL 
% & = EBCDIC 
03 FILLER CHARACTERC31) 
O02 BUFFER~OFFSET ~ CHARACTERC2) % Unused 
O02 FILLER CHARACTERC28) 


As mentioned in a prior paragraphe the MCP writes ANSII Format 
labels on tapes whenever a file is opened output and the 
LABEL~TYPE fieid in the FPB is set to zero. If the user wishes 
to continue writing the old Burroughs format labels» he must 
modify this field in ait of the files in his programs. This may 
be accomplished by recompilation» by the use of a Fite Attribute 
communicate operation within the program» by the use of the 
MODIFY controt instruction or by the use of a FILE card when” the 
program is executed. Presently valid values for the LABEL.TYPE 
fieid are: . 


ANSIT 
Uniabelied 
Burroughs 


ouou 


0 
i 
2 


ANSII Labets»s though they are written when the file is opened 
output» are actuadly created on all magnetic tapes prior to that 
time. A keyboard message has been implemented in the MCP for 
purposes of creating the initial ANSTII tabel on ait tapese The 
mnemonic of the message is "SN" which used to be an acronym. for 
Serial Number. The syntax for SN is: 


SN <unit mnemonic> <volumeridentifier> 1 ASCII 1 


<Volume identifier> may consist of one to 5ix adphanumeric 
characters and is inserted in the VOLUME.ID field of the YVOL1 
block of the tabel which is created. This cperation is» for 
conversational purposes» known as “initializing” the tape. Ail 
tapes and cassettes must be initialized on the B1000 before the 
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MCP widl consider them scratches This applies to seven=track» as 
weld as all versions of ninectrack tapes. 


The <volume identifier> keyed in wiil remain on the tape until 
the tape is rerinitiadized. The tape may be purged at any time» 
provided the ANSII tlabet is stitl intact on the tape. Tapes 
which have Burroughs labels on them must be rewinitialized and 
may not be purged. Purging» heres implies the use of the "PG" 
keyboard messagee Simitartly» unlabelled tapes may not be purged» 
but may be rewinitiatlied. The <volume identifier> is now part of 
the output of the "OL" message» The presence of the reserved 
word ASCII in an SN statement causes the tabeil to be written in 
ASCII character codes. 


The capability of creating and recognizing ANSII tlabets was not 
included in the MCP prior to the 5.0 release of the software. 
Before the 520 release» att Labels created by the B1i000 system 
were the oid Burroughs tabels first isapiemented on the 85500 
systeme A programmatic description of these labels» as they are 
created on the BL000> is shown betou. As can be seen from the 
description» certain fields have been added to the tLabels to 
improve their utility. These fieids are meaningful to the 81000 
system only. A programmatic description is presented below. 


DEFINE STANDARDeLABEL-DECLARATION AS # Z 
DECLARE OL DUMMY REMAPS L.~LABEL.~RECORD % 


» 02 L»LABEL CHAR (93 2Z ™" LABEL C™ 

, 02 L.-MFID CHAR (7) 2% 

° 02 LeZi CHAR (1) &% “0* = 

» 02 L-ID CHAR (7) 2 

s O02 L»REEL CHAR (33 2% 

ra 02 L.DW CHAR (5) & DATE WRITTEN 

» 02 LefYCLE CHAR (2) 2% “o" 

° 02 L.»PID CHAR (5) 2 PURGE DATE 

» 02 LS CHAR C1) 2% SENTINNEL C1 = END-OF“REEL) 

» 02 LBC CHAR (5) 2% BLOCK COUNT 

>». O02 LeaeRC CHAR (7) 2% RECORD COUNT 

» 02 LPB CHAR (1) & PRINT BACKUP FLAG 

’ O02 LeSERIAL | CHAR (5) 2% SERTAL NUMBER 

° 02 LeSYSTEM CHAR (5) 2% CREATING SYSTEM 

» 02 L»eBUFSIZE © CHART8) z NEW FORMAT DECIMAL BLOCK SIZE 

» 03 L»85IZE BIT(24) + 4 OLD FORMAT BINARY 

° 03 LeRSIZE BITC24) x OLD FORMAT BINARY 

» 02 L»aRECSIZE CHARTB) z NEW FORMAT DECIMAL RECORD SIZE 

ro 02 L»~MODE CHARC1) z NEW FORMAT RECGRDING MODE FOR 
x TAPE FILE 


ws 
e 


All Labels on the 81000 system are written in odd parity. 
Beginning with the 4e2 release of the softwares tape marks are 
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written in even paritys except where prohibited by the control. 
This was done as an accomodation to the B300 system» which can 
read only seven-track tape and cannot recognize tape marks which 
are written in odd parity. 


MCPII will write tapermarks and ending tabeis on any output 
labeled tape that is not at BOT when a Chear/Start is done» This 
will adilow the user to read that tape and recover the data. 
There is one restrictions. If the tape is to be read in reverses 
the user must specify blocking information.» 


ANSII labels are also written as the standard tabel = on 
seven=track tape» When this is done» the tabels are written with 
transtation to BCL. Burroughs Labels» when written to 
seven track tape» are written in odd parity with the EBCDIC/BCL 
transtator enabled. 


The STATUS Procedure makes ail possible attempts to recognize a 
dabel when a tape unit becomes Ready. On sevenrtrack tape» 
particularly» there are several different variations of parity 
and recording mode that may have been used to create the tapes 
Seven=track tape can be written with ofr without character 
translation from EBCOIC to BCL. The MCP will attempt to read 
tape labels with ali possible variations before giving up- 


When the MCP cannot recognize a tabels the unit is considered 
available for input purposes if the tape does not have awrite 
Ring in ite In this case» it must be manualiy assigned to a 
program by the operators either when the program requests the 
file or when the job is executed. Tf the tape does contain a 
Write Rings it must be initialized» using the SN instruction 
decsribed above. Onty when the tape has a Write Ring and 
contains a vatid ANSI tabedt indicating “Scratch" is it considered 
available for output purposes automaticaltly by the MCP. 


It is atso the responsibility of the STATUS Procedure to record 


the other information returned by the Test I/0 operation. This 
information is crucial to the proper operation of the tape 
subsysteme In particutars if the system is equipped with a 


PEYNRZ exchanges the operation of the STATUS Procedure when a 
unit becomes Ready is as described below. 
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PEZNRZ EXCHANGES 


With the inclusion of the M4/M5 MEC supplied by the Westlake 
Plant and described by P.5. #2047 4490» it is possible for a 
tape unit to operate in either Phase Encoded (PE) or Non-Return 
to Zero CNRZ) recording aode. This can ontiy be accomplished on 
the 81000 hardware by connecting one NRZ control and one PE 
control to the MEC. The NRZ control is designated MTC-2 and the 
PE control is designated MIC-&. <A tape subsystem so connected is 
spoken of as an exchange subsystem by hardware personnel. 
According to the software definition of a subsystem» aii controis 
in the subsystem must be identicai. The code in the 1/0 driver 
which interfaces to MTC-2 is distinctly different from that which 
interfaces with M1C~-4. A request for a unit which is operating 
in the NRZ mode can only be handled by MTC-2. 


To solve this problems considerable coding has been incorporated 
in the MCP. The problem has been rectified in the most efficient 
manner possibie» however. Two separate chains of descriptors» 
one for each controls are constructed by the MCP at Clear/Start 
time. The two chains are maintained by the MEP dynamicaily» fron 
that point. 


Recording mode information is supplied by the test operator and 
actually is returned as the density fietd in the result 
descriptor. A density selection of 1600 bpi» for examples 
indicates that the unit has been selected to be in the 
phase~encoded recording mode and that the 1/0 descriptors for the 


unit should be in the MTC-4& chain of descriptors. If the 
subchain for the unit is not in the proper chain»s the MCP will 
move the entire subchain to the proper chain. The movement of 


the subchain is only attempted when the unit is not in use» of 
COUrSe» Selecting a different density while the unit is being 
used constitutes an error on the part of the operator. The 
operator is notified of the error and the program is atlowed to 
continue processing onty when ‘the proper density has been 
selected on the unite 


This solution is only possible if both controis are capabie of 
reporting recording density properiy. NTC“2 can report the fact 
that a unit is selected to be in the 1600 bpi density. 
Simitarly» MIC-& is able to report the fact that a unit is in the 
800 bpi density. Density information is commonly used by the MCP 
only when. a unit goes from a notvready state to a ready state. 
The movement of the subchain is therefore performed by the MCP 
status routine when the unit becomes ready. 


Unit mnemonics are not affected by the presence of a PE/NRZ 
exchanges A unit selected as MTA» for exampter will always be 
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known as MTA» regardiess of which chain contains its subchain» or 
which density is selected by the operator. 


Due to differences in the unit numbering scheme between MTC-2 and 
MTC-4s there can be no more than eight magnetic tape units 
connected to a PE/NRZ tape subsystem. This capability is not 
available on any version of the software prior to the 5.1 retease 
versions 
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ELLE STRUCTURES 
A File is a group of retated recordse Files are of central. 
importance in the I/0 Subsystem since effectively alt of the 
communication between user programs and the subsystem is 


accomplished through filese 


The 81000 Gperating System supports three different file types or 
structures» exclusive of Data Management System structures» which 
correspond roughly to those file types defined in the ANSI "74 
COBOL Language. in that tanguage» these types are called 
Sequential» Relative and Indexed Sequential. Sequential and 
Indexed Sequentiadt files» in COBOL» can both te accessed’ in a 
random manner and the use of the word “Sequential” tends to add 
confusione In this document» the three types will be refferred 
to as Conventional Files» Relative Files and Indexed Files. 


CONVENTIONAL EXZLES 


The basic definition of Conventionait file structures is found in 
the COBOL *68 Languages» though many functions have been added to 
the basic definition. To a program» a fide represents a Large 
collection of ordered data that exists apart from the program. 
The program needs to interact with parts of that data from time 
to time and the I/0 Subsystem makes this interaction possibte. 
The I/0 Subsystem moves the data into and out of user working 
areas in main memory» to which the program has accesse 


The unit of data moved into and out of the user's working area is 
the record. The record is considered» by the I70 Subsystems to 
be a string of bits» which the user program will probably group 
into characters or words in some manner» but the 1/0 Subsystem 
deals only with entire records and detivers and receives one 
record at a time to and from the user program. 


A file has some structure as seen by the user programe The 
records may be atl of the same length or they may be of variabie 
length. Length information must be declared by the program or 


contained in the record itself or exist in an accessible form in 
the physical file or exist in the information which the MCP 
maintains about the file» If the record tength is variable» then 
the Length of each record must exist in that records in the first 
four character positions. 
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The file» as it is stored on some recording medium», is often 
refferred to as a physical files A physical file may have some 
additional elements of structure. It may contain biocks. A 
block is a group of physicaliy contiguous records which are 
transferred to and from the physical medium as a groupe The 


Storage device itself may impose some structure upon the file. 
As discussd previously» data is transferred to disk in 1440-bit 


increments. A btock of records to be written to disk must 
therefore total some integer multiple of 1449 bits. The disk 
itself may be used to store many disjoint physicat files. To 


minimize storage avaidability problesas» the MCP adilows disk files 
to be broken into “areas"™s» each of which wilt contain room for a 
specified number of blocks. This is described in more detait 
dater. 


The physicat fite inherits many of its properties from the 
fogical file declared by the user program which creates it. When 
the user programmer declares a togical files the compiler 
generates a File Parameter Block which contains the specified 
values for the various attributes of the file. File Parameter 
Blocks CFPBs) are defined in Section 2 of this specification. 
The MCP» and more specificaily the OPEN procedures converts the 
attributes specified by the user to an actual physical fite. 
More attributes are added to the physicat file when it is 
assigned to a device. 


Any file may be described by its attributes. File attributes are 
system control parameters which are used by the I/0 Subsystem. 
The attributes contain ait of the information the subsystem needs 
when it connects a physical file to a togical file declared in a 
user program and when it controls the access to that physical. 
file. 


Most of the attributes associated with any fide are contained in 
the File Parameter Block {(FPB) for that file. Certainty» the FPB 
is the storage medium for the attributes that are declared by the 
user and generated by the compiler. Additional attributes wilt 
be obtained when the file is opened and assigned to a device. 
When a file is open» its attributes may be stored in the FPBe the 
File Information Block CFIB)» the Disk File Header (DFH) and the 
I/O Assignwment Table CIGAT). Alf of these structures have been 
presented previously. 


Beginning with the 8.0 version of the MCPs a communicate 
operation was added to allow user programs to dynamically modify 
selected attributes of a file. In subsequent versions of the 
MCP» the List of modifiable attribtes has been expanded. The 
File Attribute communicate operation is described in the Demand 
Management section of this document. 
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ELE NAMING CONVENTIONS 


All names associated with files on the B1000 MCP may be a maxinua 
of ten characters in dength- Names in excess of ten characters 
wilt be truncated to the first tene Looking at the description 
of the FPB presented in Section 2 of this specification» the 
first field in the FPB» FPB.~FILE.NAME is the internal name of the 
file. "Internals in this case» means internal to the user 
program. This is the name which appears in the File Declaration 
of the user program and the name which the programmer uses in ail 
references to the file within the program. 


The next three name fields in the FPB provide the "File 
Identifier" for HCP purposes- Aii physical files introduced to 
the system may have one or two namese Files assigned to disk 
pack may have a third nase which will correspond to the pack 
nagaes the name contained in the pack Label. 


If a-file has one name only» that name is stored in the field 
FPB.MULTI.FILE.ID and the field FPB.FILE.ID should be filled with 
blanks. FPB»MULTIeFILE»ID is often referred to as the "Family 
ID" and is onty important if the file is assigned to disk or 
tape» If a file has two names» the second name is stored in the 
“FPB.FILE.~10 field. 


The assignment of physicat files to Logicai files is discussed in 
the Demand Management Section of this specification in the 
description of the OPEN communicate operation. Stated in its 
Simplest form» the MCP attempts to associate one or two names 
with each device that is connected to the system and that is 
capable of input operations and to match this external name to 
the File Identifier specified in an FPB when a user OPENs a file. 
On output files» the MCP simpty attempts to assign an availabie 
deawice of the requested hardware type. 


There are two exceptions to the statements in the preceding 
paragraphe When an output file is directed to Printer or Punch 
devices» the output data may be actually stored on disk for tater 
retrieval. Such files are known as Backup Files. and are 
discussed tatere Input card fites may be Loaded to disk files 
prior to the time they are required by a program. When the 
program then requests the card files MCP may automatically 
substitute the previously toaded disk files. This is known. as 
the Psuedo~Reader facility and is discussed in Product 
Specification. 2222 22650 SYSTEM/LDENTRL- 
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LOGICAL DESK EILES 


It is the MCP*s responsibiltiy to convert a logical disk file as 
deciared in a user program» to an actual physical disk file. 
This can only occur by a program opening a new disk fite»s where 
“new” in this context specifies that the program intends to 
create a file and the physical disk files that are currently 
known to the system are of no concern to the users 


Except in the case of Multi-Pack files» files that extend over 
more than one physical pack or cartridge» anew file can only 
become a permanent file that exists when the program is no donger 
executing by the same user doing a close operation on the _ fite 
and specifying in the CLOSE communicate operator that the file is 
to become permanent. This inplies that the fide identifier is to 
be entered in the disk directory and remembered by the MCP 
forever. This aiso implies that the disk storage space occupied 
by that file is to be used for no other purpose except the 
various user manipulations that may occur within that file>» 
utilizing a togicai fite with the same File Identifier. The 
Close operation is atso described in detail in the Demand 
Management section of this specification. Basicaliys the Open 
and Ciose operations both obey the rules presented in the 
definition of the COBOL Language. 


PHYSICAL DESK EILES 


In order to manage ail of the available storage space on a disk 
devices», the MCP aust maintain tables which tell it the storage 
locations that are avyailabie for uses» the names of the files that 
are already stored on the disk and the physical characteristics 
of those files. 


Disk SPACE ALLOCATION 


There are three tables» each with the same format» that are used 
by the MCP to allocate disk spacee The master available table is 
a nonwexpandable table of three contiguous segments beginning at 
the second sector on disk. It contains atist of aid unusable 
segments which have been “XD“ed”™ by the oper atore The working 
available table is a 10“-segment table beginning at the 47th disk 
segment. It contains a tist of aii. available or unused space on 
disk and is expandable as needed. The temporary table is five 
contiguous segments and contains a dist of ali segments in use 
but not reflected in the disk directory. This expandable table 
begins at the 5/th sector. At Clear/Start timer all sectors in 
the temporary table are returned to the available table. A 
programmatic description is given below: 
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DEFINE 
DISK »AVAILABLE.DECLARATION AS# 
DECLARE 
O21 DUMMY REMAPS DISK-AVAILABLE BITCSEG.SIZE)» 
02 AVL-BACK»LINK DSKeADR» 
02 AVL»}SELF DSKeADR» 
02 FILLER BITC4A )» 
02 AVL.~BLOCK(22)> 
03 AVL»ADDRESS DSKeADR» 
03 AVL»LENGTH WORD> #3 


FYLE ACCESS AND IDENTIFICATION 


The disk directory is the structure which catalogues and points 
to all files on disk. Each entry contains the file's name» type» 
and Disk File Header CDFH) address» The directory is a twor~level 
structure containing a primary or “master” directory and a 
secondary directory. The master directory is created at Coid 
Start as 16 contiguous disk sectors beginning at sector 31.2 Each 
sector contains entries for eleven files. As each sector is 
filled» another disk segment is aliocated and tinked to the 
filled sector. If a file has two names» the primary name 
CMuttin-File IDentification) is placed in the master directory 
with a pointer to a secondary directory» where all the files with 
that MFID are Listed. The secondary directory is structured and 
linked in the same fashion as the master directory. A 
programmatic description is given below: 


DECLARE O21 DIRECTORY REMAPS BASE» 


O02 ODLSK.-SUCCESSOR DSKeADR » 

02 DISK-PREDECESSOR DSK»ADR» 

02 DISK.SELF DSK ADR » 

02 FILLER BIT €12)>» 

02 DISKeNAME NAME> 

O02 DISK»ADDRESS DSKAADR» 

O02 DISK.FILE»TYPE BIT €4)» 

02 FILLER BIT C1200) X% 11 ENTRY PER SEG 


The Disk Fite Header CDFH) is a variable-length theader record» 
the size of which is dependent upon the number of declared areas 
in the file and is computed as fotlows: 


340-BITS + (€36-B81ITS *® NUMBER~OF AREAS) 


a7 St 


B1000 MCP MANUAL 
MARK 10.0 


The DFH #s never tess than 1440 bits nor greater than 4320 bits 
on diske It tists the physical characteristics of the file 
ineluding its file type and the disk address for each area. The 
following file types are recognized by the MCP: 


LOG 

DIRECTORY 
CONTROL DECK 
BACKUP PRINT 
BACKUP PUNCH 
DUMPFILE 
INTERPRETER 
CODE FILE 

DATA FILE 
VARTABLE LENGTH RECORD DATA FILE 
INTRINSIC FILE 


Disk CLLE ZTOEN TIFICATION 


As discussed previousiy»s Disk Fite Headers ({DFH) are the 


structures used to identify a file on disk. It is a 
variabletLength record which describes the physical attributes of 
the file and contains pointers to each "“area™ of the filee When 


a disk file is “opened"» a copy of the DFH is copied into memory» 
The header in memory points to the header on disk and vice versae 
There will never be more than one copy of the header for a file 


in memory at any time» Muitiple users of the file wild use the 
same copy of the header. Maintenance of disk file headers is 
covered in another section. A programmatic description is given 
bekow 2 


DISK EZLE HEADER 


DEFINE FILE*eHEADER»DECLARATION AS #% 
FHoMAPCFILE-HEADERD#>» 

FHoMAPCFILE~HEADER) AS #2 

DECLARE O01 DUMMY REMAPS FILE»~HEADER»% 


O02 FH»eUSERS»RANDOM BITCS)»% FORMERLY FH»CORE-ADDR 
02 FHeNEWFILE BITC€1)»% CLEARED WHEN NEW FILE [5 FILED. 
02 FILLER BITC7)» 

02 FH.»FILE~KIND BITC8)>» 

02 FHeSELF DSKo ADR» 

02 FHeNOWUSERS BIT (8)» 

02 FHeUSERSe«OPEN-OUT BIT C4)» 

02 FHeOPEN. TYPE BIT C4)» 

02 FHeFILE» TYPE BIT €4)-e 

02 FHePERMANENT BIT £4)» 

02 FHeJOBeWAITING»QNeCLOSE BOOLEAN» 

02 FILLER BITC9)>» ZF DON®T USE UNTILL 1977 
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02 FHeHDR-SIZE BITC14)>X% LENGTH OF MYSELF IN BITS. 
02 FHeNO*”USERS.~LOCK BITC4)>» 
* NOUSERS WHO HAVE IT OPENED WITH LOCK 
02 FHeRECORD.SIZE BIT({20)9% LENGTH IN BITS. 
02 FILLER BITC4)eoX% DON*T USE TILL 1977 
02 FH»RCOS.~BLOCK BITC20)°% 
02 FHeBLOCKS.AREA WORD» 
02 FHeSEGS.AREA WORD» 
02 FHeAREAS»RO5ST BIT C12)» 
02 FHeAREA»CTR BIT €12)» 
02 FH» EOF sPOINTER WORD» 
02 FILLER BITC4)>»ZDON*T USE TILL 1977 
O02 FH»BPS-NO BITCZO)+% 
02 FH.~BLOCK.COUNT BIT(24)e% DON*T USE TILL 1977. IGNORED 5.1. 
O02 FH»FORMAT BITC3)*2% HITHERTO =O0- FOR RELEASEs =1. 
O2 FH.~MPF BITCi)»&% HITHERTO 4 BITS. 
02 FILLER BITC24)» 
02 FH»eCREATEjTIME BITC16)»z% HITHERTO Of} HENIGE'S GENEROSITY. 
02 FILLER BITC8)» 
02 FHAUSER. INFO WORD» 
02 FHeSAVE»FACTOR BIT (€12)» 
02 FHeCREATION»DATE BIT €16)>» 
O02 FH»ACCESS.DATE BIT(16)>2 
02 FH»ASER-NO BITC24)22% DON*T REUSE TILL 1977. Sel IGNORE 
O02 $FHeMPF.»ADDR DSK»ADRe %X DONT REUSE TILL 1977 
02 FILLER BITC1)» 
02 FHeUPDATE. VERSION BOOLEAN» 
02 FHeDMS»WRITE.CONTROL> 
03 FH»DMS»TOeBE WRITTEN BOOLE AN» 
03 FHeONS»CONTROLPOINT BOOLE AN» 
02 FHeVERSION BITC363>» % YEAR» JDAY» TIME 
O02 FHe PROTECTION BIT €2)2Z% HOST RJE 
O02 FH»aPROTECTION.I0 BIT €2)5% HOST RJE 
O02 FILLER BIT €16)eZ HOST RJE 
02 FHeAREAs» ADDRESS €105) DSK» ADR» 
03 FHUNIT BIT €12)» 2% 
04 FHePORT BIT C3)» 2% 
04 FHeCHAN BIT C4)» 2% 
04 FHeSEReNOQeFLAG - BOOLEAN» % 
04 FHEV BIT C4)» 2 
03 #£-FH.ADDR BIT (24) 


MULTINPACK FILES 


The Bi000 MCP includes the capability to allow a file to extend 
over more than one removabie pack or cartridge. Such a file is 
known as a “Mudti-Pack File™ (MPF). Quite obviously» there are 
some dimitations on the use of such fides. The individual packs. 
or cartridges which contain portions of the file may not be 
removed indiscriminately. Various operational detaits | are 
contained in the "B1700 Software Operational Guide™. 
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BASE PACKS 


A multicspack file may have oniy one “Base Pack" (BP). The name 
of the base pack is the pack id as specified by the user in the 
FPB of the multictpack fite. The base pack must be on Line for 
all OPENs of the file.» The MCP may also require that the base 
pack be on tine for other operationss such as the assignment of a 
new area of disk to the file. An appropriate message witli be 
typed on the console printer by the MCP if the base pack is 
required and it is not online. The operator may then mount the 
base pack and the requesting program wilt continues The base 
pack must be on tine when the file is closed if it was opened for 
output or input/output. 


A base pack may contain single files» as well as multi-pack 
files» in any combination.» It may not» be a “continuation pack” 
for a amultivtpack fite whose base pack is a different physical 
pack or cartridge. 


The Fide header for a multicwpack file is contained on the base 
packe It contains atl information concerning the file» including 
the addresses of every area assigned on the base pack to that 
file. For each area which resides on a continuation pack» the 
header will contain the serial number of the continuation pack. 
This allows the WCP to control ali processing of the file and 
thereby avoids the necessity of updating each continuation pack 
as the file is processed. 


CONTINUATION PACKS 


A multin~pack file may» by definitions reside on two or more packs 
or cartridges When the file overflows or "continues™ to 
additionat packs» the tera "continuation pack” is used. A 
muktiwpack file may reside on up to sixteen packs or cartridges. 
There may be up to fifteen continuation packs assigned to one 
multimpack file. 


A continuation pack may be associated with only one base packe A 
continuation pack may contain only continuation filess it may 
not be a base pack for another file. A continuation. pack may 
contain information associated with more than one multi~pack 
files but ail of the files must be assigned to the same base 
packe 
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The file header» which ais contained on the base pack for a 
multiwpack file» contains disk addresses for onty those areas of 
disk which are assigned to the base packe The same statement can 
be made of continutation packss the fide header contained on a 
continuation pack contains disk addresses that are assigned on 
that pack ontye The fide header on the base pack contains the 
sertal number of the appropriate continuation pack in the disk 
address fields of the headerse 


When a file overflows from the base packs the MCP will search for 
another continuation pack that is already online and that is 
associated with the same base pack. If such a continuation pack 
is founds the file automatically overfiows to that continuation 
pack. If no such continuation pack is present on the systems the 
MCP will then search for a scratch packs one which has no files 
on its with the same type as the base pactke "Type" here means 
“restricted” or unrestricted” and is determined when the pack is 
initialized. 


If such a scratch pack is founds the file automaticaily continues 


to that pack.» If no such pack is founds the MCP temporarily 
halts the program and prints an appropriate message on the 
console printer. The program may be continued when a suitable 


continuation pack is present on the system. 


MULTI=PACK FALE INEQRMATION TABLE 


When a multicpack file is opened input» the file*s header is read 
into memory from the base pack» When a multicpack file is opened 
outpute and newe @ header is constructed in memory fron 
information in the program*s FPB and information from the base 
packs. During OPEN the MCP will find space on the system pack for 
a multi~mpack file information table. The table will contain 
specific information about the base pack» atong with an exact 
copy of the disk file header from the base pack. This copy of 
the header is treated as a working copy while the file is. opens 
The header on the base pack may therefore not always be correct. 


The format of the MPF.INFO.TABLE is presented below. One 
MPFeINFO»TABLE per fite is required» regardtess of the number of 
users. 
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02 


03 


FIELD NAME 


MPF aINFQ»TABLE 
MPF .FORWARD 

MPF eBACKWARD 
MPF »SELF 

MPF «NAME 

MPF -eHEADER» SIZE 


MPF eHEADERs ADDRESS 


MPF »BPS NO 
MPF »DPENe TYPE 


MPF ANEWFILE 


| MPF .NEW. AREA 


MPF .CS 

FILLER 

MPF »-BASE»PACK. TYPE 
MPF .ARRAY 

MPF ONLINE 


04 MPF »SERTAL.NO 
04 MPFAHDR.jDSK 
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24 BITS 
36 BITS 


DESCRIPTION 


TABLE» 
MPF TABLE. 
TABLE. 


POINTER TO NEXT MPF 
POINTER TO PREVIOUS 
POINTER TO THIS MPF 
FILE~IDENTIF IER. 
SIZE OF COMPOSITE HEADER 
MAINTAINED BY THE MCP. 

POINTER TO THE COMPOSITE HEADER 

IN MEMORY. 

BASE PACK CBP) SERIAL NUMBER. 

TYPE OF FILE OPENED.» SAME AS 
DFH»OPEN. TYPE IN DISK FILE HEADER. 


MCP FLAG USED IF THIS IS A NEW 
FILE. 
MCP FLAG USED IF NEW AREA WAS 


ADDED. 

MCP FLAG TO MARK TF CLEAR/START 
WAS PERFORMED SINCE THIS ENTRY 
WAS CREATED. 


TYPE OF PACK USED AS BP. 
1=RESTRICTED» 2=UNRESTRICTED 
USED TO RECORD ALL PACKS THAT 
ARE ON“LINE. 

MAXIMUM OF 16 ITEMS IN ARRAY. 
SERTAL NUMBER OF THE PACK. ’ 
DISK ADDRESS OF THE FILE HEADER 
ON THE PACK. 


MULTINPACK FILE GENERAL RESTRICTIONS 


In addition to any restrictions Listed in the foregoings the 
items below are also applicable to multi~pack files. 


le 


Ze 


Since a system cartridge may not be a base pack» 
on systems 


files are only 


drives 


operational 


multi~pack 
with two or more 


All packs containing any part of a multin-pack file must have 
unique serial numbers. 
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PRINIER FILES 


Ail Burroughs printers and controls have hardware capability of 
spacing the paper after writing a line of output but no 
capability of spacing the paper before writing the lines With 
the advent of the ANSI "74 COBGL Language in the 9.0 version of 
the software» the need for a more efficient means of performing 
the COBOL WRITE AFTER ADVANCING statement became apparent. In 
prior versions» this operation was implemented by the compilers» 
generated two actual I/0 communicate operators for each such 
statement encountered. The first of the two was a Position 
coamunicate or a WRITE of a tine of blankss. the second was a 
WRITE of the actual record with no paper motion specified» This» 
of courses resulted in two communicates as well as two physical 
I0s for every togical WRITE AFTER ADVANCING operation. The 
change described betow was first implemented in the 920 Operating 
System and is inctuded in ail subsequent versions» 


The goat of this modification was to reduce the number of 
communicate operations to one per Logicad WRITE and to reduce the 
physical 1/0 operations to one per communicate operation using 
the existing printer hardware. This was accomplished by delaying 
the initiation of the physical I/0 operation until the folliowing 
logical WRITE is received. By knowing both the previous = and 
current togical I/0 requests» a physical I/0 can be initiated 
which corresponds to the first request and takes advantage of the 
Burroughs hardware. 


The diagram in Figure 1 shows the relationship between the Last 
logical request issued by the usere the current logical request 
and the actual physicai I/0 operation that will be performed. 
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Current\ Pending 
Logical \ Operation 
Request \ 
i Nuit Writes No Space Write Before 
L | Single Space 
OE Nl alana le ale eel elated Sek eh lee etal el toate late eel * 
Writes 4 Noop»s 1 Write» No Space | rite» Space 1 1 
No Space 1 Pending:= 1 Pendings= | Pending?= 1 
i Write/No t Write /No 4 Write/No ] 
Saal lee heehee tele delelenhetetntenhe te tteteeatatntaleat denieahetelatetetetetatnteknbatetenten, 
Write/3 1 No7op» 1 Write» No Space 1 Write/B Space 1 ! 
Space 1 1 Pending?= i Pending== ] Pending?= | 


1 Write/B Space 1 141 Write/B Space 1  ¥Krite/B Space 1 1 
ee weaves es ses eS ees jean eee Sus Ben sen we fy [eo fF ft ky 0 =D uD OE OR OP an aE ee ee ee 
Write/3 2 Write/B Space 2 1 Write» No Space 1 Write/B Space 1 1 
Space 2 14 =Pending?=Null 1 Write/3 Space 2 I Write/B Space 2 1 


J i Pending*=Null 1 Pending?=Null 1 
FO we ROM ee ew ee Sees on fees eee e wn ees et eet ee Bees SASS Tee} 
Write/A | Space 1 i Write/B Space 1 1 Write/B Space 2 ! 
Space i 1 Pending?= | Pending?= 1 Pending?= 1 
1 Write» No Space ! Write» No Space 1! Writes No Space 1 
fone ewes wees ees es Pee eee eee ee eee my es eens es meee ee ee my 
Wrate/A 1 Space 2 |} Write/B Space 2 1 Write/B Space 2 ! 
Space 2 | Pending?= 1 Pending?= 1 Space i { 
1 Writes No Space 1 Write» No Space 1 Pending: = 1 
i i i ar ites No Space 1 


Write/B 1 Write/B Channet 1 Writes No Spare i WritesB Space 1 i 
Channel 1 Pending?=Nutl |1 Write/B Channel 1! Write/B Channel 1 


{ | Pendingt=Nuli 1 Pendingt=Nuli 1 
conten dantedantontontechatnttenlmtalelenhe i teketntadoabetadeteabalatetenlettatent, teetesteeteteettetedntetetetatedent 
Write/A 1 Space Channel 1 Write/B Channel 1] Write/B Space 1 1 
Channet 1 Pending:= j Pending?= i Space Channel 1 
1} Writes No Space ! Write» No Space § = Pending?= | 
1 4 1 Write» No Space i 
$0 wer eee eee ce ee ne perc ew eee ee seems ny ose eee ewes en ewes t 
Space N I Space x 'l Write/B Space x ! Write/B Space 2 ! 


i Space (N~x) | Space (N-x)° 1 Space (N-1) { 
1 Pending?=Nuil 1 Pending?=Nuil 1 Pendingz=Null §! 


Figure 1 = Logicail/Physicalt I/0 Relationship 


In the preceeding diagram» the operations within the table 
correspond to the actuat physical I/0 operations that witt be 
performed» Which wilt depend upon the current Logical request 
supplied by the user and any operations that are stitil pending 
from the previous request. Write/B and wWrite/A may be read 
"Write Before” and “brite After”. The symbol (C:=) may be read 
"is replaced by”. It can be seen in the diagram that some 
logical requests will» at times» result in two physicad 
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operations being initiated. Under these conditions» it may be > 
beneficial to supply each printer file with at least two bufferss ~ 
if the execution time of the program is the only concern. Totat 
system throughput will not be impacted significantly regardless 


of the number of printer buffers and the types of operations” 


being performed. If the NCP must wait for the completion of any 
printer physicat I/0 operations the time that is spent waiting 
widl be masked by the processing of other programs. 


Along these same tines» it should be remembered that any time a 
Write operation is Left pending and control is returned to the 
users the MCP must have an available buffer to store the data 


that is to be written. If no buffer is available» controi. may 
not be returned to the requesting user until a buffer becomes 
available. Again» this time will be overlapped with the 


processing of other programs and system throughput should not be 
significantly impacted» 


The action presented in the preceeding chart for a Space 
operation requires some explanation. A Space cf more than two 
lines must be handled by the 5.MCP. The Micro MCP will attempt 
to space the requested number of lines without calling the S.MCP» 
but this is not atways possibie. In the diagrams when the 
Pending operation is equal to Null» the Micro HCP wild space the 
paper one or two Lines» indicated by "x" in the diagram» and if 
N-x is greater than zero» it will pass the remainder to the 
SeMCP. Simitdarly» when the Pending operation is equai to a Write 
with No Spacer the Micro NCP will issue a Write/B Space 1 or 2 
lines» also indicated by "x" in the diagram» and if the remainder 
is greater than zero» pass it to the 5S.MCP. Khen the Pending 
operation is a wWrite/B Space i» the Micre MCP will issue a 
Write/B Space 2 and pass Nw1l to the SeNCP» jf N-1 > Of 


LINAGE Clause 


The LINAGE clause» in ANSI *74 COBOL is a mechanism which allows 
the user to define a “*Logicad Page" format and request that the 
Operating System maintain printer pages which conform to the 
defined format» as well as a current line position on that 
dogical page. In the Language» the user may specify the Logical 
Page size» an integer which represents the number of lines that 
may be printed on any page.» This attribute witli be known = § as 
PAGE.»SIZE in the remainder of this discusione 


The user may also specify an Upper Margins an area at the top of 
each page where nothing will be printed» Lower Margines a similar 
area at the bottom of each page» and a Footing area» a specified 
number of lines in the page body immediately above the Lower 
Margin areas The user may also ask to know the number of the 
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line in the page body where the Last tine of output was printed. 
This requires that the Operating System maintain a dine counter» 
which wilt be the number of tines written on the current pagee 


- 


The implementation is catited the “Logical Page” function in the 
Operating System and it includes the following: 


1.» Positioning to the beginning of the page body i-@- past the 
top margin at OPEN or at page overfilowne 


2» Reporting End-of-Page when the user writes or spaces within 
the footing area and requests EDP reporting. 


3» Detecting page overfiow. Page overfiow is defined as 
occurring whenever the execution of a WRITE would leave’ the 
line counter positioned past the page body. 


40 Updating the logical page description when switching from 
one togical page size to another. 


Essentially» the implementation obeys the rules presented in the 
ANSI "74 COBOL specifications. The operating systema will 
maintain a Line counter» a current logical page description and a 
new logical page decription. The tine counter represents the 
position on the page body fotliowing the open or the dtast togical 
writes The current togicat page description is used to detect 
end~of=page and page overflow. The new togical page description 
is used to initialize the current togical page description when 
page overflow is detected and to calculate the number of Lines to 
the first Line of the next page body. 


If the user has specified end~of"page reporting and the line 
counter is greater than or equal to the tine number at which the 
footing begins» then on completion of the WRITE» EOP is reported 
to the usere If the line counter would be greater than the Line 
nueber at which the bottom margin begins at the end of the 
Logical WRITE» an implicit position to the first line of the next 
page body is generated according to the before/after variant of 
the write statement. At this point the Line counter wilt be set 
to 1. The number of lines to skip is calculated according to the 
following formula: 


Lines.~to»skip 2= current»pageobodys»size ~ tine-counter + 
current -bottom.marginesize # newetop Marginesizes 


3746 


Bi000 MCP MANUAL 
MARK 1020 - 


The Logical Page description is updated if necessary when a write 
occurs that causes page overfiow or whenever an advance to top of 
page occurSe 


To access the Line counter requires a Fite Attribute Communicate 
from the user programs. This will be of no concern to ANSI "74 
COBOL users?> they need onty be concerned with the proper syntax 
in that Language for referencing the Line counter. The Logical 
Page definition is changed to the values inciuded in the write 
Communicate format whenever page overfiow is detected. To 
accomodate the above requirements» the format had to be expanded 
as shown in Figure 2 in the WRITE AFTER ADVANCING section of this 
document presented previoustye 


The Logical Page iaplementations since it is implemented entirety 
in softwares is useable even when the file is directed to a 
Backup mediume The Logical Page implementation is also useable 
by programs that are written in languages other than ANSI *74 
COBOL. This is effected by the imptementation of additional 
Syntax in the FILE Controt Card. Progarms may be permanently 
modified to incorporate the required new attributese The Logical 
Page function is activated by the PAGE.SIZE attribute in the Fite 
Parameter Blocke Khen a printer file is opened and PAGE»SIZE 
contains a value other than zero» page format will be controtlied 
by the Logicadi Page software implementation and the physical 
carriage control tape on the device will be completely ignored 
after the file is open. 


It is important to note that the Channel One punches as well as 
the Channel Twelve punch in the carriage controi tape is ignored 
after the file is opene According to ANSI "74 COBOL 
specificationse this is as it should be but it dictates that the 
attributes which govern Logical page format must be specified 
such that the logical page size plus the upper margin plus the 
dower margin must totai the exact number of lines on the physical 
pages If this is not dones then eventually at Least» Lines witl 
be printed on the crease between the physical pages. 


3747 


—B1000 MCP MANUAL 
MARK 10.0 


The relevant attributes may be referenced in the FILE Controt 
Card as shown betow.s 


Attribute Abbreviation Function 


AE Dy ON ORAS as ANS A DS AREY ANS ANN HOE VORA a ey A aE NN SAS A SED AA A <A a TD OS AAD AE SUBD ND ED SS VERE PS SN SOY AND GOREN RAEN ANDY TD <A ORY ARDS HANDS UND -UNRNN GEND AUD ~WONRED NNT WEDS SEN EE TIDY 


PAGE»SIZE P25 The number of Lines between the 
Upper Margin and the Lower Margin. 
May be set to any value between 1 
and 255 inctusive. 


LOWER« MARGIN Lem The number of Lines from the page 
body to the bottom of the form. 
May be set to any value between 
0 and 255 inclusive. 


UPPER» MARGIN U.N The number of Lines from the bottom 
Cor top) of the form to the page body. 
May be set to any vatue between 
0 and 255 inctusi ve. 


FGOTING Foor The number of lines from the 
beginning of the page body» 
within Page.size» to the point 
where the MCP wild begin to 
report end-of~page to the usere 
May be set to any value between 
i and 255 inciusive. 


PRENTIER AND PUNCH BACKUP CAPABILITIES 


The MCP includes the capability of directing the output data for 
printer and punch files to intermediate storage. The storage 
medium may» at the user*s option» be magnetic tape or disk. 
Backup files may not be directed to cassette or flexidisk media. 
A utidity routines named SYSTEM/BACKUPs» is provided to atliow 
users to retrieve the output data from the intermediate storage 
medium. For details on this routine» refer to Product 
Specification 2222 2661» System Backup. 


When the output is directed to magnetic tape» multi-file tapes 
are created unless the operator intervenes in some manner. if 
the operator does not intervenes the tape will be closed with no- 
rewind when the printer or punch file is closed in the program. 
The next printer or punch file which is opened by any executing 
program and directed to backup tape storage wiil then be added to 
the existing tape. This process wiil continue until the operator 
intervenes or until the physical end of the tape reel is reached. 
Operator intervention procedures are described in the Software 
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Operational Guide and in the MCP Controt Syntax Product 
Specification. 


When the output data is directed to intermediate storage on disk» 
it is entered in the Disk Directory when the printer or punch 
file in the program is closed. At that time» it may be accessed 


by any program» though the data contained therein may be 
undecipherable untess the accessing program is written expressty 
for this purpose. The file may not» under any circumstances» be 


accessed prior to the time the file is ciosed. 


BACKUP EILE BLOCKING FACTORS 


The OPEN routine in the MCP attempts to optimize the size of the 
physical blocks associated with a Backup file» according to the 
declared size of the togical records in the file. The block wiit 
typicathy be set to a size equivalent to three or four disk 
sectors» each of 180 bytes» by the MCP. In order to predict the 
block size that the MCP wilt select for any given logical record 
Size» it is necessary to consider the control information that 
the MCP stores in the first physical block of the file as weit as 
the declared record size. The algorithm that is used by the MCP 
to select a biock size is not easily described. The block size 
which is selected is stored in the file tabel» for tape files» 
and inthe Disk File Header for disk files. The togical record 
Size is adso stored in these fieids. 


Consequently» using the Oefault File <Attribute- which is 
described in the Software Qperationai Guide and in another part 
of this specification» the user may access Backup files without 
knowing the blocking factor and iogical record size in advance. 
Since the algorithm that is’ used by the MCP to caiculate btock 
size may change from version to versions this means of 
determining the blocking factor used is preferred» The algorithm 
that ais .- included in the 8.0 version of the MCP is described in 
the paragraphs that foiiow. 


The dogicat record size declared in a file in @2@ user’s program 
may be any Sizee If the file is directed to Backup storage» it 
is set to a maximus of 1352 bytes. The dtogical record size is 
then incremented by two bytese This additional sixteen bits of 
information is necessary to contain the formatting information 
which is passed with each Write and Position communicate 
operators 


If the file is being directed to magnetic tape» the record size 
is then incrementeds if necessary» to force it to a number which 
is modulo forty~eight. This is necessary since seven track tape 
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units require block sizes which are modulo six and phase~encoded 
drives require block sizes which are modulo sixteen. It would 
not be sufficient to insure that only block sizes meet this 
requirement» however» since the blocks on any tape file may be 
partial blocks which contain one or more records. 


The buffer size will always be made Large enough to contain 100 
bits of control information plus 1668 bits to. contain” the 
original Fite Parameter Block as it. appeared in the user's 
programe plus» if the file is a printer file> 1072 bits to 
contain a file tabel plus its associated spacing information. If 
the original file is a punch files a space of 648 bits. is. 
reserved for the tabel instead of i072. The one fact which 
conplicates this calculation is that alt three of the items 
listed above must begin on a logical record boundary within the 
physicat block. Consequently» for a file with a decitared record 
size of 132 bytes» which is converted to 134 tytes or 1072 bits. 
by the OPEN routinee the FPB will begin on the 1073rd bit in the ~ 
first physicad block of the file. The file fabel» if there is 
one» wilt begin on the 3217th bit €3 x 1072). The first output 
data record will then begin on the 4£289th bit. The biock will be 
made fLarge enough to insure that the first biock contains at 
feast one togicat record in addition to ait of the information 
listed above. 


For backup files which are directed to intermediate storage on 
disk» the block size computed above is then incremented» if 
necessary» to make the size module 1440. The number of records 
per block is then computed from record size and biock size. 
Endwof"File is never reported to a user program when a Backup 
file is being created. The MCP automaticaily closes the file 
when it is fuld and also automaticaliy opens a new Backup file. 
The identifier assigned to the second file will revert to the 
standard naming convention for Backup files» The MFID will be 
set to BACKUP.»~PRT and the ID field witli be set to the next 
sequential number maintained by the system. Aili other Backup 
file attributes» such as the number of copies requested» will be 
retained in the second and subsequent files. Only the name 
requested by the user will be tost. 


The MCP atso atlonws users to specify the file attributes Blocks 
per Area CBLOCKS.AREA or B.A)» Records per Bhock CRECORDS.~BLOCK 
or Re3)» and Number of Areas CTAREAS or ARE) for printer files and 
these specified values will override the system's default values 
for the same attributes. | Using the proper setting of these 
values and the automatic closing and reopening described in the 
preceeding paragraphs users may begin printing a Backup file 
white the program which created it is stitl executing and 
creating the second or subsequent portion of the same file. 
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Records in Printer files may not be blocked. Consequently» the 
Records per Block attribute is not applicable when the file is 
directed to the printer. Records per Block is utilized only when 
the file is directed to a Backup mediums Also» the value 
specified for Records per Block must be greater than a mininaum 
values which is a function of the record size associated with the 
file and which is computed by the MCP when the file is opened. 
it is reccomended that users not set Records per Block for 
Printer files in the use of this facility but establish the file 
size via the Blocks per Area and Number of Areas attributes oniy. 
For a file with 132-byte records» Records per Block will be set 
to five by the MCP unless overridden by the user. The siaplest 
means of determining the value that widil be computed for Records 
per Block by the MCP for any other given record size is to direct 
such a file to the backup medium and interrogate Records per 
Blocke 


The MCP insures that access to a backup file is in serial mode 
oniy. If the user had requested sore than two buffers on the 
original file» the number is reduced to two on the backup file. 
In a simifar manner» the MCP Limits the number of disk areas 
requested to 25. The file type in the original FPB is then 
Changed to indicate that the file was directed to disk or tape 
intermediate storage. 


BACKUP EILE CONTROL INEORMATION 


The first block in any backup file is filted atmost entirely with 
control: information. This information is used by SYSTEM/BACKUP 
when the file is printed or punched. The first twenty7four bits 
of the block will contain the logical record size» in bits» as 
computed by the prior portion of the OPEN routinee The next six 
bits of the block wil contain the number of bits that the record 
size was incremented to make it moduto forty-eight» if the backup 
mnediu®m was magnetic tape. If the backup medium was disks these 
six bits will be equal to zeroe The next eighteen bits specify 
the control information size» in bits» This field will contain 
the number of bits which are used in the first block of the file 
to contain the control informations exclusive of the File 
Parameter Block and the labed. In the 9-0 version of the MCP» 
this number wilt be equal to 1002 atithough all of the 100 bits 
may not be usedes 


The next twenty-four bits of the block will specify the FPB size» 
in bits. This nusber may vary from release to release. For the 
920 version of the software» the FPB size is 1668 bitse The next 
twenty"four bits witl contain the size of the label» if any» 
associated with the printer or punch file. This field witd 
always contain these values» regardtess of whether the file is 
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dabeied or note The next four bits will contain a number = which 
specifies the type of Label that is contained in the lLabei area. 
In all cases» at the present timer this number wilt be either 
zero» indicating a standard label» or oner indicating that the 
file is unlabeiled. 


Unless the computed togical record size of the file is exactly 
equal to the size of the control information Listed above» 100 
bits for the 8.6 version of the NCPr a filter will be added after 
the control information. This filler wiih be of a size 
sufficient to make the next field in the first tiocke the FPB» 
begin on a logical record boundary» For examples» if the original 
logical record size was i132 bytes and the backup medium was disk» 
the fidier would consist of 964 bits. 


The next field in the first block of the file wiil be the 
original File Parameter Block as it appeared in the user program 
and before any changes were made by the OPEN routinee Oniy 
pertinent informations delimited by the size specified by 
FPB.SIZE wiit be included. Following the FPB» another fitter 
will probably be required to make the next field in the first 
biocks the original fite tabeis begin on a togical record 
boundary. 


Actually» sixteen bits of spacing information precedes the file 
Label? the spacing information thus begins on the Logical record 
boundary.» For the labet» allt of the sixteen bits wili be set to 
zero» These sixteen bits widi be followed by the Label» which is 
constructed exactly as if the file had been directed to its 
intended medium originalily. The dabei is aiways constructed and 
stored in the Backup file» regardless of whether the original 
file was Labettled or not.» SYSTEM/BACKUP may or may not cause the 
label to be printed or punched» depending upon whether the file 
was or #as not tabelied. The Label in the first block wiil be 
fodliowed by a filler» if necessary» to attow the first togicat 
record of output data to begin on a logical record boundary 
Within the block. The first block wilt always contain at Least 
one Logical output records 


BACKUP EZLE LOGICAL RECORD FORMAL 


Each togical record in the file will consist of sixteen bits of 
formatting information fotlowed by the user"s output data» 
unaltereds If the togical record was generated by a Position 
communicate operators the contents of the data field are 
undefined and are ignored by SYSTEM/BACKUP.~ The sixteen bits are 
defined as follows. 
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Beginning with the 9.0 version of the software» the sixteen bits 
of carriage control information are subdivided as: 


OL CARRIAGE_CONTROL | BIT (16)> 
02 FILLER BIT €3)>» 
02 BEF ORE_AFTER BIT (€1)> 
02 CHANNEL_OR_SPACING BIT (8)> 
02 TYPE BIT (4)3 


In the description aboves the BEFORE_AFTER field is applicable on 
WRITE operations which are directed to a printer file. A one in 
this bit position indicates the operation was WRITE AFTER 
ADVANCING. The CHANNEL_OR_SPACING field corresponds to the eight 
bits of spacing information passed on a WRITE communicate in the 
CT.ADVERB fietd in the communicate operator. These bits are 
defined in the Demand Management section of this document» but 
the definition is repeated here for reference. 


CHANNEL _OR_ SPACING 
. = 0000 - No paper sotion 
0001 - Skip to Channel One 
0002 = Skip to Channel Two 


1011 = Skip to Channet Eleven 

(4100 - Skip to Channel Twelve 

‘1101 - Skip to first Line of the form ©1500 LPM 
printer onty) 

1110 ~ Single space 

1111 - Double space 


tio 


uel 


The TYPE field in the description provides information on the 
type of communicate issued by the user on this record. The 
CARRIAGE _GR_ SPACING value will have different meanings» depending 
upon the value of the TYPE fields The correspondense between the 
two is shown betow. 


TYPE Operation CARRIAGE OR SPACING Value 

0000 WRITE Printer Channel. Number 

0001 WRITE Punch Stacker Number 

0010 SPACE Number of Records to Position 

0011 SPACE Printer Channel Numbder on Position 
0100 WRITE Printer Spacing Information 
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Relative Files 


A Relative file consists of records which are identified by 
relative record numbers. The file may be thought of as composed 
of a serial string of areas» each capable of holding a tLogical 
record. Fach of these areas is denominated by a relative record 
nuaber . For example» the tenth record is the one addressed by 
‘the relative record number 10 and is in the tenth record area» 
whether or not records have been written in the first through the 
ninth record areas Relative files are faplemented using direct 
files. 


Direct Ciles 


Direct is the primitive file organization. A direct file is 
divided into a number of “record slots” of fixed length» each of | 
which may contain one record. A record slot is “*empty™ if it 
contains no valid record. Fuil record siots may be made empty by 
deleting the record they contains making the contents 
unaccessable through the normal. mechanism. Since all bit 
patterns are potentialiy meaningful as datas a separate area in 
each block of the file is maintained to indicate which record 
slots within that block have been used. There will be one such 
"Presence Bit" for each record stot in that block and the bit 
vector thus formed is known as the Block Controt Information 
CBCI). The user is not allowed to have access to the Block 
Controt Inforaation under normai circumstances. 


Relative Eile Data Structure 


The Relative file is a direct file. The blocks of the Relative 
fide contain Block Controt Information BCI) as well as data 


records. The number of data records in a block is conatined in 
the "Records per Block" field of the disk file header in the case 
of an existing file. Originally» of courses» this number is 


specified by the user programmer in his Fite Cectaration. The 
data records will be Located on byte boundaries to conform with 
the addressing capabilities of the B1006 Interpreters. The BCI. 
will therefore be padded with zeroes to insure this. when a 
Relative file is originally created» ali of the record stots are 
empty Consequentiys the presence bits in the BCI must be 
initialized when the area is adilocated. 
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Refative Eile Disk Initialization 


The use of presence bits to indicate that a record has been 
written into an available record slot means that disk areas that 
are allocated to a Relative file must be initialized when they 
are aitlocated. Ail presence bits in the Block Control 
Information must be set to zero at this time. 


When a disk area is required» the MCP will te responsibte for 
aldocating the area» and will also be responsibie for 
initializing presence bits-» If the access mode of the file is 
sequentials the MCP just allocates the area and the Logicat I/0 
routines will initialize each block before accessing it. If the 
access mode is random or dynamic» the MCP will initialize the 
entire area being allocated by automatically executing a special 
initialization program which will run at the user’s priority. 
The user witl have the option of executing this program himself» 
prior to executing the program which accesses the file» to 
initialize the entire file or any areas he chosese In the 
sequential moder if the file is ciosed with the EOF pointer not 
at the end of an areae the MCP will initialize the remainder of 
that area. 


The program which initializes newly altocated disk areas for 
Relative files is called SYSTEM/REL.INIT. If this program is 
called automaticaify by the MCP as described above» the program 
which requested the new disk area will not be adtowed to execute 
untid SYSTEM/REL~INIT has compteted the initialization of the new 
ar@ae 


Belative Eile Parameter Blocks CEPBs) 


The FPB for a #retative file is the same as for a Conventional 
random file except that FPB.ACCESS is set to a value of 2» 
indicating Relative organizatione : 


Rehative Disk Eide Headers COFHs) 


The ODFH for aeretlative file is the same as for a Conventional 
file except that the block size fieid witt include the size of 
the block control information» 
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Relative File Information Blocks CFIBs2 


The Fi8 for a relative file is the same as for a Conventional 
random file» except that a field which identifies the file as 
being Relative has been added. The field is named the 
FIBsORGANIZATION field and can assume values of zeros» indicating 
a Conventional or ANSI "74 Sequential file» one» indicating a 
Relative file» and two» indicating an Indexed Sequential file. 


Buffers for Relative files will be the same as for Conventional 
files. They wifi be allocated when the file is opened with one 
I/0 descriptor for each buffer and the buffer size equal to the 
block sizes which is equal to the record size times the number of 
records per btock plus the size of the block control information 
{i bit/record made moduio eight). 


Buffer management for Relative files will depend on the user's 
access method = Sequential» Random or Dynamic. For Random access 
the management of the buffers will be the same as that for 
Conventional random files. READ operations will be initiated on 
demand and WRITE operations will be initiated immediately after 
the Logical I/0 operation has occurreds If the access mode is 
Sequential» the buffer management will be the same as that for 
Conventional serial files. The Open procedure will filti ail of 
the buffers and the Operating System wilt try to stay ahead of 
the user programs initiating physical Read operations when the 
dast logical record in a buffer has been delivered to a user and 
initiating physicai krite operations when the last togical record 
of the buffer is received. 


The Dynamic access mode in ANSI "74 COBOL allows the user to 
switch between the Random and Sequential modes. In the Dynamic 
access mode» when switching from Sequential to Random» the last 
block is written to disk if it has been updated. When switching 
from Random to Sequential» the SMCP is called on to fill the 
buffers as if an OPEN or Position had occurred. In the Dynamic 
access mode» the access mode desired» Random or Sequential» must 
be specified in the communicate operator generated by each 
logical READ operation. 


Relative File Communicate Operators 


Three new communicate operations» corresponding to the verbs 
DELETE» START and REWRITE hawe been added to the 9-0 Operating 
Systeme To simplify the implementation and to avoid potential 
file equivalence problems» new communicate operations for 
relative files have been added to the software» rather than 
modifying an existing operation. The READ» WRITE and REWRITE 
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communicate operators have ae format which is similar to the 
format for the READ» WRITE and REWRITE communicate formats “for 
conventionat§ fitese The format for the DELETE operations on 
Relative files» is similar to the format for the same operation 
on Indexed Sequential files. The ANSI *74 COBOL START verb has 
been implemented as a new communicate and is handled by the Micro 
MCP. 
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Indexed Sequential Files 


Indexed Sequential files consist of two new primitive file types: 
Direct files and Index files. For each Indexed Sequential file 
there is one and ondy one data file and this file is implemented 
as a Direct file. For each key of the Indexed Sequential file 
there is a corresponding file of type “*index”. In the MCP code» 
these two types are Listed as INDEX.~SEQ-DATA-SETeFILE and 
INDEX« SEQe+INDEXsFILES they will be refferred to as Direct files 
and Index files in this document. 


Direct Eiles 


Direct files were discussed in the documentation on Relative 
files. A portion of that discussion is repeated here for 
convenience. More details will be found in the preceeding 
discussions A Direct file is a primitive file type that is 
divided-into a number of “record siots"™ of fixed length» each of 
which nay contain one record. A record stot is *"empty*” if it 
contains no valid record. Full record slots may be made empty by 
deleting the records they contains making the contents of that 
slot inaccessable by the normal mechanisme Since ail bit 
patterns are potentialiy meaningful as a records a bit fiag is 
maintained for each record stot to show the validity of its 
contents. 


Since aif record stots are the same size (MAXRECSIZE) the 
absolute disk address can be easily calculated from the record 
slot number. The file is divided into groups of record silots 
calied "blocks"» each consisting of “blocking factor" record 
slots plus the "Block Control Information"» a bit mask which 
indicates the presence of a valid record plus enough fitler bits 
to make the container modulo eighte There is a significant 
difference between the Block Control Information for a Direct 
file and an Index file» however. 


ZTodex Lilies 


An Index file is the second new file type. Index files contain 
fixed length records organized in tabtes with Block Controi 
Information to describe the table» Each biock of an Index fite 
wiil constitue a separate tabte. The importance of this fact 
wii be explained Later. 
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The records in the Index file consist of Key/Address pairs» The 
addresses point to other tables in the Index file or to records 
of the Index Sequential file*s data file» the Cirect file. The 
tables in the Index file form a tree structure and the records in 
the table are ordered by Key value to aliow fast random access» 
The tables whose entries point to data records are tinked 
together to allow fast sequential access. 


Cluster Eiles 


In addition to these two new file types» there must resides 
somewhere on disk» information relating ail of the various files 


which compose an Indexed Sequential file. This information is | 


maintained» by the MCP» in a third new structure which wilt be a 
separate conventional file on disk and which will be known as a 
"Cluster" file. The name of the Ciuster file with correspond to 
the user®s declared name for his Indexed Sequential file. In the 
MCP codes this file type is referred to as an 
INDEX.»SEQ--GLOBAL.~FILE» though it witt be caided merely a Cluster 
file in this documente 


The Cluster file provides the ability to reference the entire 
Indexed Sequential file structure by simply referencing the 
Cluster file. When the Compilers generate code which applies to 
Indexed Sequentiat files» they actuality reference the Cluster 
file. The Cluster file witl contain the names of the other files 
associated with the Indexed Sequential file. As mentioned 
previousty» there wild be one Index file for each key listed in 
the Indexed Sequential file. 


The statement above does not mean that all of the Index files 
will be opened when a Cluster file is opened. The Index files 
are ondy opened when they are first referenced in the program and 
this actuality happens automatically. The compilers. do not 
generate code to open the Index files. The MCP simply detects 
that the referenced Index file has not yet been opened» obtains 
the mecassary information from the Cluster file» and opens the 
fiie. 


The Cluster file does require an additional Disk File Header in 
memory» but onty while an Indexed Sequential file is being 
openede It is not necessary for it to be in memory after’ the 
file has been openedsj The Cluster file also adds an entry to the 
user*s disk directory. The diagram below shows a Cluster fite 
schematicatity. This particular file has one primary» or “Prime” 
Key and one Alternate Key. 
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This organization for Indexed Sequential files offers several 
advantages over any other. Each file» the file which contains 
the actual data and all of the Index fites» Hilti have fixed 
record and biock sizese This witt sinplify the probiem of 
managing the buffers that are assigned to the files. Both of 
these file types are nothing more than Conventional files with 
some order imposed upon the contents of the file. Consequently » 
the Disk File Headers» or “File Descriptors" required for each 
file are the same as those for Conventionai fites. This is 
discussed in more detail Later in the docusgent. 


Conceptually» this mechanism is easier to visualize and implement 
than would be auitiple structures residing in one physical file. 
Also» any of the fiies may be located on different spindles» 
which wild cleartly improve performance» since arm movement time 
may be overlapped» and access to alt of the files may occur 
asynchronously. The Direct file and the Index fite may be 
accessed independently of each other. 


The design does impose certain restrictions» which fait in the 
category of “operationat" restrictions and which do not impact 
per formaance. A checking mechanism is required to insure the 
integrity of files which are accessed independently. The MCP 
aust insure that. the correct version of the Index file is used 
with its corresponding Direct filee Also» some extra memory for 
Disk File Headers witt be required» since more actual Headers 
widl be required. A naming convention for ati of the files must 
be imposed» thus removing some small amount of generality from 
the user's capabilities. This may actuatty be an advantage» 
however » The naming convention is iaplemented in the Coapiter >» 
not in the MCPs though this may not be apparent to» and should 
not be important to the user. 
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The Ctluster fiie is a Conventional data file which contains the 
information relating ait the component files of the Indexed 
Sequential file. The structure of the Cluster file is similar to 
the Data Base Dictionary format in the Data Management Systeme 


eens aes Oe 1 OS 2 EE 8 ID ee eS ee mam as ae f 


! Index Sequential I 1 

| Fite Globals p2seSe).. 4 

1 j 1 1 
$28 e> peewee ewes esce seer sceesee= oem my 1 { 
| 1 OFHEXTENSION» Structure 1 1 i 1 
1 po one eee eee eee we ees en es ee eey 1 1 
{ { DFHEXTENSIONs Structure 2 1 1 | 
i (Pete ee ewan sess ses seen esses asent 1 1 
i / / I 1 
i / / i | 
i $a cee e ene sews cree seseces oe ---- + ! 1 
{ 1 DFH.EXTENSIONs Structure n 1! 1 1 
i f Pewee s ae ee ee ee wees em eT See eT Owe eC Eee 1 
1 I File Table - Contains ait of j 1 
ited | the names of the subfites 1! | 


PF ews Vesa TF VeFT FFB BTSs M Hs HMB H SHB saws), ¢ snow ws} 


1 Structure Desce Structure 1 1 


} Structure Desc. Structure 2 1 
J / 
f i 


1 Structure Desc» Structure ni! 


+= = 2 an as se an 6s ee ee ee ee ee ee a oe es 


The DFHeEXTENSION and Structure Descriptor fields shown above are 
both discussed in the paragraphs that fotlow. The pointer shown 
above from the File Table is one of manye There is an entry for 
each file in the File JTable and each entry has a pointer to its 
associated DFH.EX TENSION. 


ITadexed Sequential Data Eile Structure 


The data file of an Indexed Sequential file is a Direct fite. 
The blocks of the data file contain Block Controt Information 
CBCI) and data records» simidiar to the blocks of a Kelative file 


as presented previouslye The number of data records in a block 
is specified by the Records per Block field of the disk file 
header « A similar structure is used on Indexed Sequential files 


in the Data Management System. Btock Control Information for the 
Index fites associated with ali Indexed Sequential files is 
significantly different from that for Relative files. 
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Todexed Sequential Index Eile Stcucturce 


Index files contain records consisting of Key/Address pairs 
within a block. The file itself ts a tree structure whose nodes 
are blocks» Each biock of the file is anode or table. The 
first node is the root table. The root tabte and tables on all 
levels except the fast are cadiled coarse tables. The tables in 
the fast tevel of the tree are called fine tables. Entries in 
coarse tables point to the next tevel tabte whose highest entry 
matches the key of the coarse table entrye Fine table entries 
point to a record in the Direct fiie whose key matches the fine 
tabie entry (CSee Figure 3). Fine tables are tinked together in 
logical order te provide fast sequential access and easier 
Current Record Pointer CCURRENT) maintenance. 


The addresses in these tables are not absolute disk addresses. 
Instead» they are thirty"two bit combinations of an area number» 
a segment number within the area and a displacement into the 
segment. This displacement is merely the record number within 
the biock. Adi addressing of Index tabies as weli as of records 
in the data file is accompiished on a retative basis as opposed 
to an abdDsoiute one. 


The blocks in Index files contain Block Controt Information of a 
different content and format. The format and content of the 
Biock Controt Information maintained in an Index file is shown 
below. A simiiar structure exists for DMS Index files. 


O01 INDEX.FILE BCI BIT €38)>» 
02 BC.TYPE BIT €2)2% O=COARSEs 1=FINE 
O02 BC.~PRESENT-RECORD.jCOUNT BIT €12)>» 
02 BC.NEXT.»LOGICAL .BLOCK BIT €243%% VALID FOR FINE TABLES 


The individual records in the Index files have a fixed formats 
since the Key specified by the user must be contained in these 
recordss the size of the records may vary with the keys but the 
format wild always be as shown below» The same format is used by 
the Data Management System for records in Index tables. 
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01 INDEX.»RECORD DECLARATION» % FOR DMS AND ANST *74 INDEX FILES 


O02 ITR»POINTER» 
03 IRsAREA.~DISP» 


04 IReAREANMBR BITC8)» 
03 [ReOFFSET BIT(8)» Z VALID FOR FINE TABLES 
O02 IRKEY BITCKEY.SIZEI5 


The organization of an Index file is shown in the diagram below. 
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Figure 2 - Index File Organization 


This structure for the Index files ailiows the implementation of 
the most efficient search and addition algorithms. Linking the 
last tevel of the fine tables together aldows efficient 
sequentiat access of the records in the data file. Using this 
Link» the CURRENT need only point to the last entry accessed in 
the fine tables and not to the path through the coarse tables to 
the fine tablese This ekhiminates the need for restrictions on 
the number of tevets aitowed in order to maintain the CURRENT. 
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It also makes checking for changes in the CURRENT> caused by 
other users accessing the files easier. 


The Fite Parameter Block (FPB) of the Cluster file of an Indexed 
Sequential file wild be positioned in the code file among the 
other FPBs according to the order of it*s declaration in the 
user®s source codee In addition to the information normattly 
contained in an FPB for a Conventional file» a Ciuster file FPB 
widi contain a type fietd which identifies it as a Cluster file 
FPB»s a pointer to the data file FPB and an integer which > 
indicates the number of keys associated with the Index Sequential 
file. There wild be one FPB for each Key dectared and these FPBs 
will immediately follow the FPB for the data file in the code 
file of the programe This is shown in the diagram in Figure 3. 


Defautt vatues are used for the file attributes of a Cluster 
file. The user may not change these values. The number of disk 
areas witli be set to ones records per block will be set to one» 
block size will be set to 180 bytes and blocks per area wilt be 
set to 50. The ALL»AT.~OPEN boolean will be set» causing the disk 
area to be allocated when the file is opened for the first time. 
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* New field in 920 Software 


Figure 3 = Code File on Disk 


Some changes were also necessary in the Program Parameter Block 
in the 9%20 software. The changes. are required to prevent 
programs which contain Relative and Indexed Sequential files from 
being executed on versions of the MCPs released prior to the 9.0 
version. Further» program code files which are executed under 
control of the 920 MCP may no tonger be executed under control of 
any prior MCPs. For this reasons users who anticipate returning 
to prior versions of the NCP are advisad tc retain copies of 
their code files and to not execute these copies under control of 
the 9.0 software. 
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indexed Seguential Memory Structures 


Generally» the memory structures used in the Indexed Sequential 
implementation are much like the current Data Management Systesn 
memory structures» with but a few exceptions which take advantage 
of the more specific requirements of the ANSI ‘'74 COBOL 
definition. Unlike DMS» which does not use File Information 
Blocks in memory» Indexed Sequential files will have an FIB 
dictionary entry which will point to an Indexed Sequential FIB. 
Since the files may be shared among the programs that are 
executinge this FIB will contain only the information pertinent 
to a specific user and wiil be referred to as the User Specific 
Information CUSI) fieid. 


The USI wiil contain a pointer to the file specific information» 
the information that relates only to the file itself regardless 
of who is using it. The central element in this structure is the 
information necessary to relate the various component files of 
the Indexed Sequential file. This is actually global 
information» globad.to ait of the users» and will contain a tabte 
whose entries point to information specificatly concerning the 
component file. The structure which contains this information is 
referred to as the Index Fiie Structure Descriptor CSTR). There 
wild be one Structure Descriptor for the data file and one _ (for 
each Index file assoctated with the Indexed Sequential file. 


Structure Descriptors contain pointers to the DFH» Buffers and 
CURRENT information associated with the various Index files. The 
relationship of the various memory structures used is shown 
diagramaticaily in Figure 4. 
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Figure 4 ~ [-S File Memory Structures 


EIB Dictionaries. 


From the uwser*s view point» Indexed Sequential files are more 
like a Conventional Random  fite» except for the fact that 
symbolic key values are used» than they are Like DMS structures. 
Though the Data Management System is a superset of the Indexed 
Sequential inplementations the user is more tikely to have 
several smait. and transient Indexed Sequential files than one 
large file which he would treat as a data base. 
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A secondary» but important» goal of the design of the ANSI *74 
COBOL implementation was to allow a smooth integration of 
Relative and Indexed Sequential files with the Conventional fite 
mechanisme For this reason and for other reasons» access to an 
Indexed Sequential FIB is via the FIB Dictionary» which is also 
used to access Conventional file FIBs. The FIB for an Indexed 
Sequential file is itself quite different from the FIB for a 
Conventional file. The Indexed Sequential file is associated 
with several physical files» whereas the Conventtonat file is 
associated with only one» Also» more than one user may share the 
information» including the data buffers» of an Indexed Sequential 
FIB; a Conventional file FIB is used by oniy one user. If two 
users are accessing the same physical Conventional file» each 
user will have his own FIB. 


For these reasons» an Indexed Sequential FIB contains three major 
parts: 


le User Specific Information 
2e File Global Information 
3-2 Component File Specific Information 


The entry in the FIB dictionary corresponding to the Indexed 
Sequential file points to the User Specific Information CUSI) of 
this Indexed Sequential FI8-. 


Todexed Sequential User Specific Information CUSI) 


The USI contains information associated with one user only. The 
MCP must know how the user has opened the file» for example as 


INPUT» and how the user is accessing the _ fite>» such. as 
sequentialiy. This information is kept =in the USI. User 
statistics» status and MCP workspace are aiso kept in this 
structures Finatly» there is a pointer to the next part of the 


Indexed Sequential FIB»s the global information associated with 
the physical file. 
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O01 USER»SPECIFIC.INFORMATION» 


02 FIB.COMMON.PORTION BITC22039Z% The first 

03 FIB.~BOOLEANS BIT{5S8)» ZX 220 bits of 
04 FIB.OPEN BITCil)» X USI are the 
04 FIB.CLOSING BITC1)» % same as 
04 FIB.-OUTPUT BITCid» ZX Conventional | 
04 FIBAINPUT BIT(1)>» Z FIBs 

03 FIBsORGANIZATION BIT(4)» Zz 
% 1 = RELATIVE 
% 2 = INDEXED/SEQUENTIAL 

O02 USI.~FIB»s 

03 FIB.LUSI.~NOT»FIRST.~jTIME~THRU BITC 1)» 

03 FIB.USI-LAST.OP.READ BITC1)>» 

03 FIBAUSI-DUPLICATE BiTtC1)» 

03 FIB.~USIT.~MATCH.~FOUND BITC i)» 

03 FIB-USIT»UPDATE.FLAG BITC1)» 

03 FIBLUSIeFIRST»APASS BITC1)» 

03 FILLER BiTC2)» 

03 FIBUSI.ACCESS.MODE BITC4)» 

03 FIB.USI. JOB«aNUMBER BiIT(24)» 

03 FIB.AUST~RECORD»~ADDRESS BIT(C24) 5 

03 FIB.USI-KEY.-POINTER BITC24) >» 

03 FIBeUSI»COMMUNICATE»WORKSPACE» BiI¥€616)» 
04 FIB~USI.BINARY SEARCH. ARGUEMENTS BIT{208)> 
04 FIB~UST~INTERFACE.PADS BITl(96)>» 
04 FIBeUSI*SAVEeSTATEsAREA BITC 312) 

03 FIB.USI.GLOBAL.~POINTER BIT(24)>» 

03 FIB.USI-CURRENT.»~STRUCTURE BITC 8) >» 

03 FIB.USIAHEADER BIT(C24)>3 


Indexed Sequential Eile Global Information CGLOFPALS) 


As shown in the above diagram» the first 220 bits of the User 
Specific Information are the same as the first 220 bits of an FIB 
for a Conventionat file. The rest of the information can be seen 


to be items that are peculiar to a specific user of the 
structures It is information that is necessary for Operating 
System storage of the “state” variabies that may be required to 


perform a single operation for this usere 


Included in this information is a pointer to the-next portion of 
an Indexed Sequentiat FIB» the file Global information. This 
informations known as the GLOBALS fietd» contains information 
about the various physical files which comprise an Indexed 
Saquential file. Its main function is to provide a path to the 
required fides necessary to complete an I[/0 operation. A 
secondary function is to store information global to the Indexed 
Sequential file. 
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The path to a particular component file is provided by a system 
descriptor contained in a tabte of system descriptorse The first 
entry of the table points to the data file. The remaining 
entries point to Index files» one for each key declared; they 
appear in the order of the declaration of their corresponding 
keys. For any operation which specifies a key» the compiler witd 
specify the key numbers» which wild be used as an index into this 
table. 


The global information consists of pointers to the chain of I/0 
descriptors to be used for operations on the Indexed Sequential 
data file» a count of users who are updating the file» and Lock 


bits to support ANSI "74 COBOL*s file tevel teckoute Also 
contained in GLOBALS are the count and flag fields necessary to 


enforce the prohibition on concurrent updatase A programmatic 
description is shown below. ; 


O01 GLOBALS 
02 GLOUB.~VERSION.~NUMBER BITC8)>» 
02 GLOB.NUMBER.OF USERS BITC6)>» 
02 GLOBeNUMBER. OF -UPDATERS BIT(6)s— 
02 GLOBADISK.»COPY.ADDRESS DSK.» ADR » 
02 GLOB.SIZE~IN-BITS BITC16)» 
02 GLOBeMNEMORY»ADBRESS BITC24)» 
02 GLOB.LOCK.BITS BITC2)> 
02 GLOB.I0.DESC.CHAIN. ADDRESS BITC24) » 
O02 GLOBe MAX »STRUC TURE NUMBER BITS)» 
O02 GLOB.~FLAGS BIT(6)» 
03 GLOB.~DNS.FILE BITC1)>» 
03 FILLER BITC4)» 
03 GLOB-WRITESERROR BITC1)» 
02 GLOB.CONCURRENT.~INFO> % AT THIS DMS INFO AND 
03 GLOB.»INUSEjCOUNT BITC{6)5 % TS INFO ARE DIFFERENT 
03 GLOB. CONC URRENT.FLAGS» X TIL STR DIRECTORY 
04 GLOB.FILEAVAIL BITC1)> 


04 GLOB.UPDATE»REQUIRED.OR»INPROC BITC)» 
O02 GLOB»STRUCTURE.DIRECTORY- 
03 GLOBeSTRUCTURE.DESCRIPTOR SYeDESC » 


All of the pointers to subsequent portions of the Indexed 
Sequentiadi structures aii oof which are known as Structure 
Descriptors» are contained in the GLOBALS fietd. This simplifies 
the task of maintaining the structures and it allows the buffers 
to be shared among the various users. It adds one tevet of 
indirection to alt accesses to the data of courses but this 
expense is small for the benefits it yields. 
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The Structure Descriptor is similar to an FIB for a Conventional 
file except that aif of the User Specific Information is removed 
and maintained in the USI field. For the Index files of an 
Indexed Sequential structure» necessary key information is also 
kept in the Structure Descriptore For examples the position of 
the key within the data records» it*s size» whether or not 
duplicates are attlowed»s and whether or not it is the prime key 
are ati stored in the STR. A programmatic description is shown 
bel owe 


OL STRUCTURE_DESCRIPTOR> 


02 STRe NUMBER BITC8 3» 
O02 STReTYPE BITCL4&)» 
02 STReUSER COUNT BIT(6)» 
02 STReBUFFER»LOCK BITC2)» 
O2 STR»eBUFFERSLIST.POINTER BIT(24)>» 
02 STR-RECORDS.PER.}BLOCK BIT{B8)» 
02 STReSEGMENTS»PER-}?BLOCK BITC8 I» 
O02 STReRECORD.SIZE BITC16)>» 
O02 STR»~BLOCK.SIZE BITC16)» 
O02 STReBLOCKS.»jPEReAREA BITC16)» 
O02 STR»SEGS»PER»AREA BITC16)» 
02 STR»DFH. ADDRESS BIT(24) » 
O02 STR» DFHAOFF SET»~TOEXTENSION BIT(16)» 
02 STReCURRENT»jPOINTER BIT(24)> 
02 STReFLAGS 

03 STRePRIMESKEY | BITC1)» 

03 STReDUPLICATES»jALLOWED BITC1)» 

03 STR»SIMPLE.KEY BITC1 )» 
O02 STReSPLITFACTOR BITC12)» 
O2 STR»KEY.~INF Os 

03 STReNUMBER.OF KEYS BITCS)» 

O4 STReTTEMOFFSET BITC16)>»> 
04 STRALTTEM.SIZE BITC12);>3 


As shown in Figure 4° the Structure Descriptor contains a pointer 
to the Disk Fite Header» the MCP-defined structure which is at 


the tast tevel. This structuree as it always has» contains 
information retating almost exclusively to the Physicat 
characteristics of the fite. Any togicai information in the 


header» such as record size and records per block» was obtained 
from the program whith originaliy created the file. 


The format of the disk file header had to be expanded in the 9.0 
version of the software to accomodate the ANSI "74 COBGL 


jiaplementatione Prior to the creation of the 9.0 versions 
several pieces of information associated with OMS Data Bases» 
which shoutd have been part of the OFH» were maintained 
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separately due to a lack of available space in the then curent 
definition of the disk file header. These fields have also been 
incorporated in the new disk file header. The new tormat has 
been designed to prevent the occurrence of such probleas in the 
futures whenever the need for new fields in the DFH arises. 


Disk Eile Header Extensions | 


Some efficient means of available disk space maintenance had _ to 
be devised for Indexed Sequential files.» To accomptish this» the 
necessary information regarding the available space is maintained 
in the Cluster file as a data record. When an Indexed Sequential 
fide is opened» this information is brought into asmemory and 
Stored in a memory area which witl immediately follow the Disk 
Fille Header for the data file. This area is known as the Disk 
File Header Extension. 


Zodexed Sequential Disk Eile Header Extension 


When the Indexed Sequential file is opened» the information on 
the avaitaole space within the Direct file» atl of which space is 
not available as far as the system is concerned» is brought into 
memory and stored in the DFH Extension. The format of this 
information in memory is as shown below. 


O01 DFH.TS EXTENSION» 


02 FILLER BIT(16)>» 
O2 DFHAIS-EXTENSION.SIZE BITC16)>» 
O2 DFHATSe-EXTENSION.VERSION BITC36)>» 
02 DFHeISeNEXToFREE-RECORD BITC32)» 
02 DFHATS»NEXT»FREE.~BLOCK BITC32)>» 
02 DFH.IS-ROOT.~TABLE — BITC24)>» 
O02 DFHeIS-UPDATEsFLAG BIT (€1)3 


Indexed Sequential Available Space Ailocation 


The Indexed Sequential file system maintains two fields in the 
DFH-EXTENSIGN of each file which keep track of available space 


within the Direct file. This avattable space should not be 
confused with the available disk space that is aaintained by the 
Systeme Available space in an Indexed Sequential file or in a 


Relative file means that a record has never been written into an 
available record siot or that a record was written at some time 
but was subsequently and is now deleted. To the systems ail of 
the space ailocated to the file is in use and none of it is 
availabiee 
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Both of the available space pointers shown above» 
DFHeLTSeNEXTFREE~RECORD and DFH.I5.-NEXT.FREE .BLOC Ks wiil contain 
addregses of bilocks which have available spaces The 


NEXT»FREE-RECORD pointer does not actually point to a record but 
points to the block which contains the available record stots 
Record stot atlocation within a block is accomplished using the 
presence bits in the Block Controt Information for that block. 


The DFHeTSsNEXT»FREE.~BLOCK field witht contain the area and btock 
number of the next totally available block at the togical end of 
the files The first disk area of the data file is afitocated when 
the file is first opened and the NEXT.FREE.~BLOCK field is set to 
zero». a valid address» at that time. Also» when the file is 
first opened» the NEXT.wFREE.RECORD field is set to aFFFFFFFF 3. 
When the Micro MCP needs to add arecord to the file and the 
NEXTeFREE*RECORD field contains @FFFFFFFF a» it means that no 
records are availabte in a bitock that has aiready been 
initialized. The allocation must be accomplished using the 
NEXT»FREE-BLOCK field. 


i 


The Micro MCP will then initialize the Presence Bits in the Block 
Control Information of the block addressed by the NEXT.FREE.-BLOCK 
field» move the address which is in the NEXT.FREERECORD fietd>» 
in this case @FFFFFFFF2 to the first thirty~two bits of the tast 
record stot in the blocks move the address of this biock to the 
NEXT.-FREE-RECORD field and increment the NEXTeFREE~BLOCK fieid. 
If the incremented value of the NEXT.~FREE-BLOCK field causes this 
disk area to exceed the specified size of a disk areas 2FFFFFFFF a 
wild be stored in the NEXT.»FREE~BLOCK fieid instead. The use of 
this value is discused in a subsequent paragraph. 


The record which is being added is then moved te the first record 
slot in the newly allocated blocks the presence bit for this stot 
is set and the block is written. The presence bits for the 
second and all subsequent record stots within that block will be 
set to zero» due to the initiaiization process» @FFFFFFFFa» the 
value that was previously in the NEXT»FREE»~RECORD field» witt be 
stored in the first thirty*two bits of the dast record stot in 
the block» 


When the next record is added to the filer the Micro MCP witd 
again examine the NEXT.FREE»~RECORD field and it will now contain 
the address of the block that was just allocated. The Micro MCP 
wifil read the block into semory» if necessary» and examine the 
Presence Bits in the Block Control Information. The first 
avaidiabie record stot wilt be the second stot within the block. 
The Presence Bit for this stot will be set and» if this is the 
Last record stot in the block» the @FFFFFFFF2 stored in the first 
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thirty-two bits of the record stot will be moved back to the 
NEXTeFREE-RECORD field» and the record will then be stored in the 
slot. If the second record slot is not the Last in the block» 
OFFFFFFFFa wiil remain in the actual tast stot and the 
NEXTeFREE*RECORD field will not be changed. 


Atiocation in the Direct file will proceed in this sanner>» 
asuming that no DELETE operations are performed» until the disk 
area becomes filled and» as mentioned previously» a@FFFFFFFF2 is 
stored in the NEXTeFREE»BLOCK field. This value serves as an 
indicator to the Micro MCP that the next disk area has not yet 
been ailocated by the $NCP. When the Micro MCP encounters this 
vaiue» it merely passes control to the SeMCP which widt allocate 
the area and store its address in the disk file header and in the 
NEXT»FREE»BLOCK fielde The Micro MCP wild then initialize the 
Block Control Information and proceed as was described 
previousiy. 


The process just described may be interrupted by the occurrence 
of a DELETE request from a user» When this occurs» the address 
in the NEXTeFREEsRECORD stot is stored in the first thirty-two 
bits of the record being deleted» the Presence Bit associated 
with the deleted record is reset and the block is written to 
disk» The address of the block which contains the deleted record 
is then stored in the NEXT-FREE.RECORD fieid. The next time a 
record is added to the file» it will consequently be stored in 
the area occupied by the record that was just deieted and the 
NEXT»FREE-RECORD field will be restored to its prior vatuee This. 
operation should eliminate the need to periodicaily rewrite the 
entire file to eliminate targe numbers of empty record stots» a 
process commonly known as “garbage coltection". 


Should more than one record in a block be deleted» the Micro MCP 
only needs to insure that the first thirty-two bits of the Last 
available record stot in that block contains the address of the 
next block in which a record stot is availabde or @FFFFFFFFa if 
there is no such next blocke This is true even if att of the 
records ina block are deleted. No pointers need be changed» in 
this latter case» until the next DELETE operation occurs. 
Assuming that no new records have been added in the interim» the 
Micro MCP then needs only to insure that the address of the block 
which is totally empty is stored in the stot previousiy occupied 
by the deleted record. 


Allocation of space for an Index file associated with an Indexed 
Sequential file is somewhat sispler than for a Data file» since 
record availability does not have to be maintainode Whenever a 
record is deleted» the pointer to that record in the Index fite 
is destroyed and the table contained in the block is compacted. 
The count of the actuai number of entries in that blocks which is 
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maintained in the Block Control Information of an Index file» is 
decremented. No other action is required for the Index file. 


Maintenance of the NEXT.FREE»BLOCK field of an Index file is 
exactly like that for the data file. This fieid will atways 
contain the address of the next available block at the togical 
end of the file. The Micro MCP will set the field to aFFFFFFFFa 
when the next disk area must be altocated» exactly as is done for 
the data file. 


The NEXTe~FREEeRECORD field is used to address a tinked tList of 
. blocks within the file that are compieteiy empty. This can only 
occur when all of the records that were addressed through this 
block have been deleted» a situation which should seldom occur in 
actual use@e 


dZodex Eile Table Splitting 


The “splitting” of fine tables in the Index file is an operation 
that is always performed by the S-HMCP. Any time the addition of 
a record to the file causes a need for a fine tebte to be divided 
in two» the Micro MCP passes control to the SDL portion. 
Consequenttiy» the S.MCP perforas most of the available space 
maintenance for the Index filess while the Micre MCP performs the 
majority of this work for the data file. 


Cutcent Record Pointer CLURRENTO 


The CURRENT is a structure that» for ANSI "74 COBOL» logicaltly 
belongs in the User Specific Information field» since there is 
only one CURRENT per usere There are two reasons for associating 
the CURRENT with the Structure Descriptors» however. First» OMS 
has a CURRENT for each structure and a pointer exists in each STR 
to the appropriate CURRENT. To be compatibiea with DMS» each STR 
of an Indexed Sequential file points to the CURRENT for’ that 
structures. A current structure number is maintained in the USI 
to satisfy ANSI *74 requirementse Seconds» since the file can be 
shared» an operation by one user can affect the CURRENT of 
another user. To guard against this» each CURRENT is checked 
when an operation which can affect it is performed. To aid the 
search of CURRENTs» they are tinked together» the first one being 
pointed to by the STR» A programmatic description of the CURRENT 
field is presented betow. 
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021 CURRENT_DECLARATION> 
02 CUReLINK BIT(24)>» 
03 CUR.CUR. JOB BITC16)» 
03 CURCUR»~INVOKE BIT({6)> 
02 CURSTATUS BIT(2)>» %Z% OM-DEL» I-VAL 
02 CUR»eFINE «TABLE» 
03 CUR.AREA BITC6)>» 
03 CUR~BLOCK BITC16)>» 


03 CUR.-RECORD — BIT(12)> 


CURRENT Maintenance 


The current is maintained for Indexed Sequential files which use 
either Sequential access or Dynamic access. When the user is 
accessing the file sequentially» the current is maintained for 
the key of reference CUSI.CURRENT.STRUCTURE). For output files» 
the key of reference must be the prime key and CURRENT atways 
points to the last entry written. For anew file» CURRENT is 
initialized to point to the first entry but CUR.STATUS is set to 
indicate the entry has not yet been writtene For an old fide 
opened OUTPUT EXTEND» the current is initialized to the last 
entry written. The Micro MCP uses the current on output files to 
insure that records are written in sequences a requirement of 
ANSI 74 COBOL. 


Sequential INPUT or INPUT-OUTPUT files require that the current 
points to the last record read. On the next READ operation» the 
current is incremented to point to the next available record. If 
the current record is deieted or the CURRENT was positioned by an 
QGPEN or START» then CUR~STATUS is set to indicate that a record 
has not yet been reade The next READ wilt deliver the record and 
reset CUR-STATUS. . 


For files in Dynamic access mode» the meaning of CURRENT is more 
conplicated. The CURRENT will be handled exactly as in the case 
of Sequentiat INPUT or INPUT-OUTPUT. This means that some 
sequences of operations may not produce the desired intuitive 
result. The example below idiustrates the problen. 
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Consider the Index tab4e at the right. poswes sonny 
What should the result of a READ NEXT i ABLE | 
be» in the fodtowing sequence of operations? 1 DOG 4 

i GOLF 1 
ae READCABLE)» ADDC BAKER» READ NEXT? foe ewe swe ny 


be READCDOG)» DELETEC DOG)» ADDCECHG)» READ NEXT> 
ce READC DOG)» DELETEC DGG)» ADDCCHARLIE)> READ NEXT> 


For our implementation the READ NEXT produces the following 
results: 
ae BAKER 
b» GOLF 
ce» GOLF 


# 


Indexed Sequential Buffer Management 


The method of atlocating buffers in prior versions of the MCP and 
in the 9.0 version for Conventional files is known as Static 
allocation. This method of allocating buffers is simple» once 
the number of buffers has been chosen by the user. The buffers 
are merely adtocated when the file is opened and they remain 


assigned to the file until it is closed. If the number of 
buffers allocated is too saaii» however» then operations upon the 
file may be inefficient. If the number of buffers allocated is 


too largess then nothing is gained in efficency and memory space 
is wasted. ' 


On an Indexed Sequential file particularly» the number of buffers 
actually needed varies with the type of operation and the state 
of the Indexed Sequential file. The optiaum number of buffers is 
best chosen dynamically to avoid the disadvantages mentioned 
above. 


Allocating buffers on demand and deattlocating them when the 
memory they occupy is required for other purposes is known as 
Dynamic allocation. Dynamic atliocation has alnays been used for 
buffers associated with a DMS data base. It is accoaplished by 
cailing the NCP*s memory allocation procedures» GETSPACE» whenever 
a buffer is required. Deailocation is accomplished by allowing 
GEYSPACE to overtay OMS buffers when necessary. Dynamic 
allocation has also been implemented for Indexed Sequential 
files» 


The management of buffers associated with an Indexed Sequential 
file presents a special problem for the NCP» since there can be a 
variable number of them» depending upon the operation» and they 
can be different sizes» depending upon which component file is 
being accessed. To solve the probteas associated with a variabie 
number of buffers» the Prioritized Memory Management aigorithms 
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developed for the 7-0 release should be used. This memory 
Manager overlays buffers whenever space is needed and the 
priority of a buffer makes it a candidate to be overlaide The 


FIFG Memory Management algorithm can be used but performance may 
be impacted ona muiti~programming system. 


To solve the problems associated with variable size buffers 
addressing the same Indexed Sequential file» att of the buffers 
used for one structure are tinked together and pointed to by’ the 
structures so that ali buffers in a chain are of the same size. 


indexed Sequential Buffer Descriptor (BD?) 


The Buffer Descriptor is the structure used to saintain the 
buffers associated with the Indexed Sequential file. It contains 
the necessary tink fields» identification fields» and state 
informatione Since the memory manager may overlay the first 
buffer in a chains the memory tink field» ML.POINTER» witt 
contain the structure address so that STR»BUFFER-LIST.POINTER may 
be updated. A prograamatic description of the Buffer Descriptor 
is presented betiow. . 


01 BUFFER DESCRIPTOR» 
O02 BD.AREA-DISPLACEMENT>s 


03 BD.AREA BIT(B)» 

03 BDOFFSET BIT(1 6)» 
02 BD.~USER.~COUNT BITC4&)» 
02 BD-~IN MEMORY BITC1)» 
02 BDeLTO-ERROR BITC1)» 
O02 BD.~WRITER»CONTROL> 

03 BDeREQUIRES~AeWRITE BITC(1L)» 

03 BDeCONTROL»POINT BITC1)» 
02 BD.NEX7./jBUFFER.DESCRIPTOR BIT(24)» 
02 BD»PRIORBUFFER.DESCRIPTOR. BIT(24)>s 


I70 descriptors are shared among all the buffers. The BEGIN and 
END addresses in the descriptors may be modified when a 


descriptor is used by the Operating Systeme The number of 
buffers aitlocated depends on the number of active structures 
associated with the Indexed Sequential files | This technique 


serves to minisize the number of descriptors in the disk chains 
thus reducing the amount of processing required by GISMO» and it 
minimizes the memory requirements for descriptors. It does 
require an aliocation mechanisa for descriptors» in addition to 
one for buffers» but this expense has been found to be worth the 
benefits. 
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Concurrent Yodate Operations 


Concurrent READ operations on the same record of an Indexed 
Sequential fite are always allowed. For the 3.0 version of the 
softwarer all dogicai update operationass WRITE and REWRITE» wilt 
be started only. after att accesses to the file have been 
suspended.» These update operations wiil inhibit further accesses 
to the file until they complete. To userses it wilt appear that 
concurrent updates to the file are allowed» though this will not 
actually be the case. 


This restriction simplifies the code necessary to insure that the 


appropriate buffers remain in memory. Since only one update 
operation can be in process at any given time» the update 
operation wilt begin with a BD~USER-COUNT of zero. Once the 


update operation uses a buffer» that buffer*s user count will be 
set to onere thus preventing the Nemory Management algorithm’ from 
overlaying it. 


Upon coapletion of the update operation all user counts wiifl be 
set to zero. For READ operations» the user count field is not 
used because each buffer need be used only once during the 
process of the communicate. The buffer is automaticaity 
protected from being overtaid while the I/0 operation is in 
processes 


The code necessary to insure the integrity of the file is also 
simplified. The Record Contention problems» the comptex probtiems 
involving changes to the file while another user is accessing it» 
are avoided. For the simple case of one user at a time updating 
the file» The siaplified code provides better performance. 


Disk 120 Ecroc Procedures 


The disk I/0 error procedures in the MCP perform a certain number 
of retry operations each time a disk I/0 operation completes with 
the Exception Bit» Bit 1 starting. from zero» set to onee 
Different procedures may be invoked» depending upon the type of 
I/0 operation that has compieted and the type of control and 
drive that encountered the error» MCP I/0 operations are handted 
by a different procedure which is not as extensive as the one 
described betow. The foltowing description appties to I/0 errors 
on user I/6 operations only.» 


The I/70 error procedure first checks the Memory Parity Error bit» 
Bit 5 in the Result Descriptors received from the control. If 
the bit is on» it performs a maxigum of three retry operations» 
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hogs the result and exits the procedures without investigating 
any other bits in the result descriptor. 


The procedure next checks the Transmission Parity Error bit» Bit 
15 in the result descriptor. If this bit is on and if the unit 
being used is not a B9482 disk cartridges» the procedure performs 
@ maximum of three retry operations» togs the result and exits 
the procedure without checking any further. If the unit is a 
BI4B2» no retry operations are performed for this case but and 
the investigation continues 


The procedure next checks the Not Ready bit» Bit 2 in the result 
descriptor. If this bit is ony» the procedure performs a maximun 
of three retry operations» logs the result and exits the 
procedure without checking any further. 


The procedure next checks the Write Lockout bite Bit 6 in the 
result descriptor. If this bit is on» The procedure looks at the 
1/0 descriptor itself. If the first three bits of the operation 
code are 010» 011 or 1015 which would denote Kkrite» Initialize 
and Relocate» the procedure performs a maximus of three retry 
operationse togs the resuit and exits the procedure without 
checking further. If the first three bits denote something other 
than the three operations listed» Bit 6 is ignored and the 
investigation continues. 


The procedure next performs a Logical OR operation on? 


it. The Sector Address Error bit» Bit 10» 

Ze The Seek Timeout bit» Bit Lis 

3. CThe Address Parity bit» Bit 9» AND not B9482)» and 
&. The Data Error bit» Bit 3. 


If the result of the Logical OR operation is true» the procedure 
becomes complex and varies with the type of disk connected. 
Before describing the procedure for each type of disk» some basic 
procedures should be described. 


Ihe Qffset Procedure 


The Offset Procedure is a subroutine of the disk I/0 Error 
procedure. Basicatiy» it performs six retry operationse If any 
one of the six effect recovery of the errors the procedure is 
exited tamediately regardless of how many operations have been 
per formed. The term “offset"™ as used here denotes positioning 
the disk heads slightiy off of the center of the cylinder 
specified in the disk address. In atid disk pack drives which may 
be connected to the B1000 system» offset may be specified in the 
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inward Cpositive) or outward Cnegative) direction. 


The first two operations requested by the Offset Procedure are 
performed with the original i/0 descriptor unmodified. The next 
two operations are performed with negative offset and the tast 
two are performed with positive offset. If recovery is not 
effected by any of the six» adi bits which may have been set in 
the original I/0 descriptor to cause the offset operations are 
reset and the procedure is exited. 


Ihe Sicobe Procedure 


The tera “strobe"™ as. used here denotes beginning the actual read 
operation sligtiy before or after the point in the rotation of 
the disk where it would normaliy begin. The Strobe Procedure 
calis the Offset Procedure a maximun of three timese This may 
cause a maximum of eighteen retry operations to be perfornad. If 
any one of the eighteen effect recovery» the procedure is exited 
regardless of how many operations have been performed. 


The first call-on the Offset Procedure is accomplished with the 
original I/0 descriptor in its unmodified form. This wili cause 
Six retry operations to occur» axactiy as described for the 
Offset Procedures provided recovery is not effected by any of the 
Six» The next cali is accomplished with a bit set in the 
descriptor which will cause early strobe to occur. Hences 
another six retry operations may be performed» two with early 
strobe and no offset» two with esarty strobe and positive offset 
and two with earty strobe and negative offsete 


Twelve retry operations have been performed to this point. If 
the error has not yet been corrected» the Offset Procedure is 
again cailed with bits set in the 1/0 descriptor to cause tate 
strobe to occur. This may result in another six retry operations 
being performed» as described for the Offset Procedures att with 
bits set in the I/0 descriptor to cause tate strobing to occur. 


If none of these eighteen operations effect recovery» all bits 
which may have been set in the 1/0 descriptor are reset and the 
procedure is exited. In the Strobe Procedure and in the Offset 
Procedure» if any retry operation does effect recovery» the I/0 
descriptor resposibie is entered in the flog prior to exiting the 
Procedur ee 


3781 


B1000 MCP MANUAL 
MARK 10.0 


Ihe Error Correction Procedure 


Ail varieties of disk pack that may be connected to the 81000 
Systea and some varieties of disk cartridge inciude error 
correcting capabilites in the form of a Fire Code remainder. 
stored immediately after the i440-bit data segment. The 
remainder is fifty=six bits in tength on the 207 disk pack and 
thirtyctwo bits in tength on ail others. It is computed and 
stored by the disk hardware when the data segment is written. If 
an error should occur when the data segment is read» the data as 
it should have been written may be reconstructed» provided att of 
the bits in the data that are incorrect reside in the same 
"burst™ of bits and provided the length of this burst does not 
exceed a specified timiting number of bits. | 


The Error Correction Procedure obtains a 2°Q080~bit buffer from 
available saemory. If such memory is not available» the routine 
exits without attempting to correct the error. In all cases» 
when error correction is performed» all of the segments described 
by the original descriptor are read and corrected one sector at a 
tine. For all disk devices which store the 32-bit remainder but 
which do not have the ability tm correct burst errors in input 
data» the procedure aust operate in this manner. Devices which 
are capable of performing error correction» such as the 207 disk 
drive» are capable of doing so on multiple-sector read 
operations» but this feature is not utilized by the software. 
Rather» ati of the sectors are read one sector per operation and 
the exact addresses of adil failed sectors are toggede This 
information would be tost on a multiple-sector read operations 


Error correction is performed by the software for all. varieties 
of disk pack except the 207. The 207 hardware includes error. 
correcting capabilities. Error correction is aiso performed by 
the software for the 89482 Disk Cartridge. The software is 
capable of correcting a sixsbit error burste The 207 hardware is 
capable of correcting an eleven-bit burst. 


Data and Address Ecror Becovery - 213 And 223 Drives 


Two different varieties of 215 and 225 disk pack drives have been 
delivered during the life of the B1000 hardware. These varieties 
are known as Design Levei One CDL“1) and Design Level Two (DL~“2). 
For both varieties» the Strobe Procedure is invoked but there are 
some operational differences in the hardware itseif. On DL-1 
drivess the bits which cause plus and minus offset and early and 
date strobing are ignored by the hardware» since it does not 
inctude these capabilities. Consequently» on DL-1 drives» a 
total of up to eighteen retry operations wilt be performed by the 
Strobe Procedures but they widt actualiy be nothing more than 
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eighteen repetitions of the original I/0 descriptor. ODL*2 drives 
include a full complement of offset and strobe capabilities. The 
software cannot distinguish between the two types of drive. 


If none of the eighteen retry operations caused by the Strobe 
Procedure effect recoverye the I/0 descriptor is restored to its 
original state» and the Error Correction Procedure is invoked. 
Each segment described by the I/0 descriptor is read individually 
and error correction is performed» if possible» by the software. 
In alt cases» the results of the recovery attempt are entered in 
the Engineering Loge 


Data and Address Error Recovery = 295 And 206 Drives 


For 205 and 206 disk drives» the Strobe Procedure is performed 
exactly as it is described. Eighteen retry operations are 
per formed» two operations with each possible combination of the 
strobe and offset variants. If any of these operations effect 
recovery» the I/0 descriptor is restored to its original 
condition and the procedure is exitede If not» the Error 
Correction Procedure is invoked with the I/0 descriptor in its 
originat condition. Error correction is performed by the 
software for 205 and 206 drives- 


Ia any casee the results of the recovery atteapt will be entered 
in the Engineering Log prior to exiting the procedure. The 1/0 
descriptor is aiways restored to its original condition prior to 
exiting the procedure. 


Data and Address Error Recovery = 207 Orives 


207 disk drives inctude neither offset capabilities nor strobe 
capabitities. The hardware does inciude a capabilty to vary the 
threshotd of a read operation but its use is not recommended § for 
recovery purposes by the manufacturing plant. Consequentiy» the 
Strobe Procedure is not invoked for 207 drivess Two retry 
operations only are performed» both using the criginal version o 
the I/0 descriptor. If either operation ef fects recovery» the 
results are logged and the procedure is exited. If note the 
Error Correction Procedure is invoked- 


207 drives include error correcting capabitities in the hardware. 
Additionattlye the hardware is capable of correcting aii errors 
that are correctable in afl sectors described in one muitipte 


sector operation. This multiple sector capability is not 
utilized by the software» howevers and each sector is read and 
corrected individuaily. This is done for diagnostic purposes 
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only» to isolate the address of the failed sector(s) and insure 
their entry tn the Engineering Log» The results of the recovery 
attempt will be Logged and the procedure wilt be exited with the 
I/D descriptor restored to its original condition. 


Data and Address Errore Recovery - Disk Cartridges 


For. ait versions of disk cartridge except the B9482» the 4400 
BPI» 203 or 406 track» 64 sector per track variety of cartridge» 
the error recovery procedures are very simpte. The procedure 
merely repeats the original operation a maximum of three times» 
The resuits of this attempt are togged and the procedure is 
exited with no further checking. There are no other options 
available in the hardware which wight heip in the recovery 
attempte 


For the B9482 cartridge» the recovery attempt is slightfy more 
extens ives This drive has error correcting capabilities similar 
to those of the 206 drive. Error correction on a Read operation. 
is performed by the software in the Error Correction Procedure 
exactly as it is described. Qn a Write operations the recovery 
attempt is actuality more complex than for a disk pack» 


When: a Write error occurs on the 89482 cartridge» the I/0 Error 
procedure will attempt to correct the error» if the three retry 
operations mentioned above fails by writing the data one sector 
per operation. In the case of an Address Parity errors the 
procedure witli adso attempt to write that sector plus the 
preceeding sector in an effort to correct the address parity. 
The results of the attempt wilt be logged and the procedure witt 
be exited when recovery is effected or when ali retry attempts 
have been conpieted. 


This concludes the discussion of Data and Address Error Recovery 
for the various drives that may be connect. The remainder of 
this section describes the remaining tests in the I/0 Error 
procedures 


Remainder of the Disk 1/0 Error Procedure 


If the results of the Logical OR operation mentioned previousty 
were false» the I/0 Error procedure examines Bits 22 and 23 of 
the result descriptor. If both bits are set to one» they 
indicata that an Extended Resudt Descriptor was returned with the 
operations though the ERD may not be stored in wmemorye The 
procedure stores the Extended Result Descriptor »- if it is 
available» in the Engineering Log and performs 4 maximum of three 
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retry operations using the original I/0 descriptor. The results 
of the attempt are logged and the procedure is exited with no 
further checking. 


Finalty» if all of the tests mentioned to this point were false» 
the procedure performs a maximum of three retry operations and 
logs the results. Since an exception did occurs indicated by the 
setting of Bit il» the data is assumed to be corrupt and an 
attempt is made to correct ite 


dape [40 Ecror Procedures 


There is one I/0 Error procedure that is invoked for atl tape I/0 
operations that complete with the Exception bit in the result 
descriptor se@te The procedure is invoked regardless of whether 


the operation was a user I/0 or an MCP I/0. It is also invoked 
on the compietion of Test operations» where the setting of the 
Excepton bit #§s a normal occurrence. It is atso invoked § for 


Emulator Tape operations» though in this cases it may do nothing 
more than. pass. the result descriptor on to the user for 
resolution. 


Essentiatiy>» the procedure wili retry the operation a fixed 
nusber of times and return control to the procedure which catted 
it» If recovery was effected» this wiit be so indicated in the 


previously faited resuit descriptor upon returns Tf the 
procedure was not able to effect recovery» the result descriptor 
widd contain an indication of the failure upon returne In most 


instances» the procedure will retry the operation ten times» but 
this number will vary with the type of failure and the operation 
attemptede 


The Tape 1/0 Error procedures wilh be described fully in a 
subsequent version of this specification. 
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SINEMORY MANAGEMENT AND MEMORY REQUIREMENTS 


This section of the specification has two principle parts.» 
S“memory management is described at the functional tevet. 
S*memory requirements for a given system configuration are then 
presented. Using the second part of this section» it should be 
possible to estimate the amount of S-memory that wild be required 
on a system to support a given program, 


S“memory management techniques were changed drastically in the 
7.0 version of the software and were changed again in the 91 
versions The discussion contained in the first part of this 
section may not be applicable» in aill cases» to versions of the 
software released prior to the 9el versions 


GENERAL MEMORY MANAGEMENT CONCEPTS 


The BLO00 software utilizes a "segmentation" form of memory 
management.» In such a system» memory is requested and atiocated 
only when it is required and only in the amount that witli exactly 
Satisfy the request. In other words» memory is divided into a 
variable number of segments» each of which is of any sizes with 
some obvious restrictions. A basic element in this form of 
memory management is the “memory Link™. | 


The format of the memory Link was presented in a prior sections 
Basically» it contains a size fieid which may contain any value 
from zero to 167770215 bits. It contains the addresses of the 
memory links that precede and succeed it and the address of an 
associated segment dictionary entry. It contains a number of 
other fields» which wild be discussed in turne. It is created and 
maintained by the MCP and the executing interpreters store 
selected information in ite In ali cases» it immediatety 
precedes the segment of memory that it describes. 


LINKED MEMORY 


Contiguous blocks of memory are reserved for system use at the 
extreme ends of the memory on any systeme This is described in 
more detail in the second part of this section. Between the two 
contiguous blocks Lies the area knoun as “inked memory". At the 
end of the reserved area at the low end of memorys there is a 
dummy memory Link known as the Lower Terminating Memory Link 
CLIML). At the beginning of the reserved area at the upper end 
of memory is the Upper Terminating Memory Link CUTHL). 
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The terminating memory Links are created during the Clear/Start 
procedure. Each has a size field of zero» a type field which 
specifies the area as TERMINATING.»LINK» but the “save” bit wild 
be set to one in both linkse This ailows the memory management 
procedures to recognize the terminating memory tinks. The 
backward pointer. in the LITML witli contain @FFFFFFas but the 
forward pointer wilt contain the address of the next memory Link» 
in address order. Simitarty» the backward pointer in the UTML 
wilt contain the address of the previous memory tink in address 
orders the forward pointer will contain IFFFFFFa. 


Hence» alt memory links form a chain in memory» The memory Link 
which immediately precedes each adtocated memory area will 
contain the address of the succeeding and preceding memory links 
in the forward and backward pointer fietd respectively. The 
chain will be terminated in the forward direction by the upper 
terminating memory Link and in the backward direction by the 
lower terminating memory Link. 


The area known as tinked memory is an example of a “memory 
subspace”» as this term is used hereine There may be other 
memory subspaces within linked mesory. The Run Structure 
€Base/Limit area) of certain programs may aiso be divided and 
allocated upon request by the software. The same procedures in 
the software are used to manage these smaller memory subspaces as 
are used to manage Linked memory. 


TYPES OF MEMORY REQUESTS 


Memory requests may originate in a number of diverse manners. 
This is evidenced by the Large number of different values’ the 
type field of a memory link may. containe The most common 
occurrence of a memory request is for a code segment to be 


brought into memory. Other requests originate when a file is 
opened» when the MCP needs additional temporary storage for the 
performance of one of its tasks» when additional space is 


required to hold a queue messages and so forth. 


There is probably no need to discuss each different type of 
memory request» Many of the numbers assigned to each different 
type of memory request are for the benefit of the Dump/Analyzer 
program onty and have only pathological use. The different types 
of requests have common characteristics and may hence be grouped 
into "classes". The common characteristics will be described and 
explained. : 


Parameters that are passed with a memory request are the size of 
the required memory area in bits» the address of the dictionary 
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entry which wilt be associated with the memory arear if any» the 
address of the Run Structure Nucleus of the program which caused 
the request» if any» the type field to be stored in the memory 
Link» the priority of the request» a bootean variable which 
specifies that the memory should be atliocated at the highest 
possible physical address and a boolean which specifies that the 
memory must be aifdocated above the “fence”. 


THE FENCE 


The MCP has one set of stacks» anly» to store the variables that 
it must manipudate in the performance of any functions This set 
of stacks cannot be stored anywhere elses they must be 
Raintained in memory until the function has been performed. 
Consequently» once the MCP begins performing any function» it can 
perform no other function until the original task is complete. 


Almost alt MCP functions require more than one MCP code segment 
to conplete. A file Open may require more than thirty code 
segments to be brought into memorys The number of code segments 
required could obviously be reduced by making each code segment 
larger but this woudd also reduce the possibility of finding 
sufficient memory on small systemse It would also possibty cause 
more user code segments to be removed from memory to make room 
for the Larger MCP segment» 


Should the MCP begin performing a certain request and not be able 
to find sufficient memory to contain a necessary code segment» 
the system would have to halt. A Clear/Start would then be 
required» with its resuiting toss of aii programs that were 
running at the timee In order to insure that there will atways 
be sufficient memory to bring in the largest MCP code segmente a 
fence is estabdished in memory» betow which only code segments 
are ailowed to reside. The tLocation of the fence may be 
calculated by adding the size of the Largest MCP code segment and 
its associated segment dictionary to the address of the lower 
terminating memory Linke 


Certain exceptions to the statements in the paragraph above 


exist. Code segments may not be overlayabie at all times. To 
bring a code segment into memory» the memory area is allocated 
and an I/0 operation initiated. The memory area may not be 


deallocated untit the 1/0 operation is comptete-. Shoutd the MCP 
encounter such ae situation and not be able to find a required 
memory area anywhere else in memory» it wild wait for the 
completion of the operation. 
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Certain code segments associated with MICR applications programs 
are also not overtayable. This is adso true of segments of the 
interpreter used by such programs» Consequently» the fact that a 
memory request is for a code segment is not sufficient to 
determine whether the memory should be allocated below the fence 
and the boolean variable is required. 


MINIMSZAIION OF “CHECKERBOARDING"” 


Checkerboarding» also known as Externat Fragmentation» is the 
condition which exists when memory contains a Large number of 
permanentlycattlocated areas» or "save" arease most of which are 
separated by smalt overtlayabie areas. In such a situations the 
total memory avaitable may well be large enough to satisfy a 
given request but no single contiguous overlayabie area is 
sufficiently large. This situation can have a serious impact 
upon per formancee 


To minimize the possibility of the eccurrence of checkerboarding»s 
the MCP attempts to allocate aid memory denoted as 
noawoverlayable or “save"* at the highest possible physicat 
address.» Examples of items which are so allocated are progran 
rum structures» files and 1/0 buffer areas. 


MECTiN SELECTION 


When a request for memory allocation is receiveds the management 
algorithm must select a “victia"» a portion of memory which is 
already aitlocated which may be dealiocated and assigned to 
satisfy the new requeste The area to be allocated may aiso be 
waarked Available» of courses though this ts seldom the case. 
"Victim Selection” is the process of determining which aliocated 
memory segment or segments will be dealtocated. This is the most 


intricate task of the management adgorithms the task which 
requires the most attention to strategy and the task which is 
most influential upon the performance of the system. Two victia 


selection algorithms are provided in the software. Users may 
choose either the priority Victim Selector or the Second Chance 
Victim Selector via a system option. The change is only 
effeccted during a Clear/Strat operations 
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ROUND“ROBIN VICTIN SELECTION 


Prior to the 7.0 release» victim selection was essentially a 
round"robin among requestse The MCP kept a pointer which served 
as the starting point of each search and was updated after. each 
aldocation to point to the end of the newly aliocated area. This 
pointer is typicaily referred to as the “left~-off pointer*. The 
round“robin atgorithm had the advantages of being computationaily. 
sisaple and it served to minimize external fragmentations but 
there are some sertous disadvantages associated with this victin 
selection atlgorithme Specificatlys 


1. It has no knowledge of which segments are actually in use» 
elements of the "working set™» and 


2e The memory resources of each job have equal importance. 
Untike processor scheduling» the memory is not allocated on a 
priority basis-« 


These flaws tead to some bad performance degradations in certain 
Situationse One such problem is the “cascading” phenomenon. 


Using Denning*s definition» a program’s working set WCT» t) is 
the set of all segments accessed by the program in the interval 
CT~ts» T]. Denote the size of this set Cin MCPII context» size is 
in bits)» as WtTs td. This definition affords us useful 
information with which to manage reali store whenever the change 
C"drift") from the set WOCTO» t) to the set WiCTi» t) is smalt 
for the interval [TO» Til. The assumption behind working set 
management is that for many programs» the drift is indeed smati 
during most of their execution Lifetines. 


Postulate a situation where the code and dictionary segments of a 
single job completety fill overlayable memory. The round-robin 
algorithms having no information concerning WCT» t) made a choice 
of victims among the resident segments which was essentiaily 
random with respect to this information. Catl the ratio 
WOT» t7(size of overiayable aemory) the saturation ratio 5S. 
Then the probability is approximately 53 that the incoming segment 
wild overtay one or amore elements of WCT» t). The overtayed 
segments of courses will immediately be needed again and has a 
probability of about 5 of overlaying another element of WC(T» t}. 
This sets up an undesirabise osciltation which should eventuatty 
damp back to stability» assuming no further external 
perturbances. The probable number of extra overlays required to 
reach stability increases with S» and becomes quite iarge when 5 
exceeds» sayr 0429s We cali this oscillation "cascading" of 
overtays. For targe values of 5S» almost ali time is consumed in 
waiting for I/B on the backing store» so very Llittie work gets 
done» This is the situation commonly known as "thrashing". 
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NOW» suppose the memory manager has some knowledge of the 
elements of WOT» t)d~ If the saturation ratio is not too close to 
ones it witl usually be possible to select a window containing no 
element of W{T» t). The chance of cascading segments is thereby 
decreased in configurations running with S tn the range of 0.5 to 
0+f5-2 The difficulty is that eiements of WCTr td now clutter 
memory and increase external fragmentation. As S$ approaches Cor 
exceeds) one» this becomes an important toss and makes selection 
difficult for the memory manager. At this points the advantages 
of the round-robin strategy begin to outweigh the advantages of 
utilizing working set information. 


WORKING SET DETERMINATION 


In order to determine whether or not a code segment in memory is 
currently being used» usage bits were added to the memory tink in 
the 7.0 version of the softwares These appear in the 
prograamatic description of the memory Link as 
MLePREVIQUS»SCAN.»~TOUCH and ML.~CURRENT.jSCAN.TOUCH. Whenever an 
interpreter accesses a code segment dictionary entry and = finds 
the associated code segment present in menorye it sets the 
current scan touch bit to a value of one. Interpreters make such 
an access whenever they are reinstated and whenever a code 
segment transition occurs It is not necessary for interpreters 
to set the bit in memory Links which are associated with segment 
dictionaries. These are usually marked as save space if any of 
their code segments are present in memory. Aiso»e data segments 
are always overtaid in a rounderobin fashions» regardless of the 
victim selector that is currently being used on a system. 


SECOND CHANCE VICIZM SELECTION 


The Second Chance victin selection algortihms first introduced in 
the 9ei version of the MCPs addresses the first failing of the 
round*robin algorithme the lack of knowledge of the working set 


of the code being used» Aisop the Second Chance atlgoritha 
completely supplants the old round "robin strategy- The latter is 
no donger available for use. The change is complatety 


transparent to users and the only noticeable effect should be an 
improvement in performance tn installations where the round-robin 
algorithm was used prior to release of the 9.1 software. 


The Second Chance algoritha utilizes the teft-off. pointer 
described for the round-robin atgorithme It begins searching for 
a memory space targe enough to satisfy the request at the 
Left-off pointer but it wild not select any space whose touch 
bite ML»CURRENT.»SCAN»TOUCH» is set» Upon encountering a memory | 
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segment whose touch bit is sets» it resets the bit and continues 
to the next memory tink. {It wild allocate the first segment it 
encounters that is sufficientty large and whose touch bit is 
reset. 


This algorithm thus has the major advantage of the rounderobin 
algorithms it is computationally siapite and the procesing 
required is minimized. Undiike the Prioritized victim selection 
algorithm described belows it requires no knowtedge or action on 
the part of the user. 


PRIORITY VICTIN SELECTION 


The second faitiing in the roundtrobin strategy is its inability 
to insure rapid turnaround to jobs which are designated as. high 
priority» In MCPIIe prior to the 7.0 release» onty the processor 
was allocated on the basis of priority. A high priority 
application was contending for the memory resource on exactly the 
same footing as a low priority “background™ job. This ted to 
severe performance degradation for users. which required many 
overlayabie memory resources but frequently relinquished 
processor control to make operating syste#a requests. In 
particulars datacomm applications running in aultiple job shops 
were suffering badly. Background jobs tended to usurp criticad 
resources forcing the datacomm application to toose controt stilt 
more frequently» allowing background jobs to runs» grab more 
mamory resources» and so forthe 


The Prioritized memory management algorithm» first introduced in 
the 7-0 version of the MCP» addresses both of these problems. 
The priority victim selector makes its choices on the basis of a 
priority field in each memory Link. This field is maintained by 
runtime use of working sat informatione The priority field will 
be maintained at its original vaiue as tong as the code segment 
is not used-e This field is known as the Residence Priority fieid 
and is shown on the programmatic memory tLink description as 
ML «RESIDENCE .PRIORITY. 


Associated with each program running on the system is a Memory 
Priority field.» The memory priority value determines the ability 
of the program*s code segments to overlay the code segments of 
other programs running on the system. Memory Priority is stored 
in each memory tink associated with each of the program's code 
sagments - It is shown programmatically as ML.INCOMING.»PRIORITY. 
Mesory priority is atso stored initially in the Residence 
Priority field. Whenever a request for anew code segment to be 


brought into memory is received> the memory priority of the 
associated program is compared to the residence priority of every 
memory Link currently present in the system memory. The current 
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iaplementation of the victim selector always chooses a victin 
having the Lowest residence priority. 


An exception must be made for MCP code segments» As presented in 
a prior paragraph» the MCP cannot be denied a requested code 
overlay without halting the systena.  Consequenttye MCP code 
segments have an imperative incoming priority» but their 
residence priority vatue will decay at a rate equal to or greater 
than the programs running on the system. 


At a uservwspecified interval» a routine in CISMO known as the 
sweeper is executed. This routine moves the setting of. the 
current touch bit to the previous touch bit» destroying the prior 
setting of the previous bit and setting the value of the current 
touch bit to zero. This routine is discardable and is eliminated 
by the initializer if the system is running with the Second 
Chance victim selectore 


The default time period between executions of the sweeper is 800 
milliseconds. Users may vary this time period via a keyboard 
instruction within certain ranges» Since the sweeper routine may 
be executed between any two Soper ations» alt code in the 
software which manipulates memory Links must always insure that 
the chain formed by the address pointer fields is intact» 


After the sweeper has moved the current touch bit to the previous 
touch bit» it then examines the previous touch bit. If the vatue 
is. zero» it increments the current decay interval field» 
ML »CURRENT.DK»INT» by the value of the sweep interval. If the 
value of the current decay interval is equal to or greater than 
the specified decay inteval»s NL. OKeINTERV AL» the residence 
priority field is decremented. 


The default value of the specified decay interval is zeroe Users 
may specify different decay interval vaitues via a keyboard 
instructione Users may also specify that certain code segments 
within a program are important and that their residence priority 
should not decay until the specified decay interval has elapsed. 
This is accomplished via a supplied normat-state program which 
manipuiates code files resident on disk. The residence priority 
of code segments which are not marked as important will decay 
after the default decay interval» zero. seconds» has elapsed. 
Notices however» that this cannot occur for at Least one sweep 
interval. 


When executing with the priority victim selector» the MCP stild 
maintains a left-off pointers. When the system is thrashing» when 
the residence priority fields of all memory tinks have equai 
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values» the victim selected will continue to be the next memory 
area below the Left~off pointer. 


PROGRAMMATIC DETECTION OF MEMORY THRASHING 


One of the serious probieas confronting virtual storage systems 
is memory thrashinge On the B1000 systems memory thrashing 
occurs when the working set of procedures for a program or set of 
programs wifi not fit within the portion of main memory avaitabtle 
for overlayse When this state occurs» the systea’s performance 
begins to degrade. The amount of degradation depends on the 
‘overlay space avattable»s the size and nureber of segaents 
competing for memory» and the frequency of segment transitions. 


As the amount of main memory is reduced for a constant 
programming task» the amount of degradation due to memory 
overlays normally appears very gradual at “first. As the 
available memory is further reduced» a point wiit be reached 
where the degradation due to overlays increases rapidly. This is 
the point where the main working set of procedures no Longer fit 
in main memory and are competing for space. This point is 
defined as the thrashing point and is shown in Figure 4.1. 
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As seen in Figure 401» execution of the programming task with 
less memory than indicated by the thrashing point yields 
inefficient execution times in region A. 


Beginning with the 7.0 version of the software» the MCP includes 
a programmatic facility for detecting a thrashing condition in 
the systems The facility is included in GISM0O as a discardabile 


segments it is retained or discarded during the Clear/Start 
operation based upon the setting of a system option. It may be 
used with either victim selection aigorithn. It must be used if 


the priority victim selection atigorithm is used. 


The facility is actuated by a clock maintained in the softwares 
It utilizes a count of the number of overilay operations performed 
by the softwaree The count is also maintained in the software» 
of courses The sweeper routine discussed previously is actuated 
by the same clock that actuates the thrashing detection routinee 


At a usersselected intervals» the thrashing detector compares the 
number of overlays which occurred during the interval to a 
user=specifted target number of overlayse If the overtay target 
is exceeded» the thrashing detector suspends teaporarily the 
execution of the sweeper routine and begins a count of the number 
of consecutive intervals during which the number of overlays 
exceeds the target nuaber. The ailtowabie number of intervats 
during which thrashing» as defined by the user» is detected is 
three. 


If the thrashing condition persists for three intervals» the 
software informs the operator via a SPO message. The message 
wilt be repeated at N»eSECOND intervals untit the condition abates 
or until the operator requests» via another SPO message» that it 
not be disptayed continuaily. The software aiso disabtes the 
schedule when thrashing is detected so that no new jobs are 
initiated. The schedute will be automatically enabled again uhen 
a program currently being executed terminates. 


MEMORY INTTIALIZATION 


Memory is initiatty attlocated by the software during the 
Clear/Start operation. This single operation is composed of 
severai cosponentse For discussion purposese it may be thought 
of as two separate operationse The first of the two is the 
execution of a stand-alone routiner commoniy known as the 
initializer and stored in the disk directory as SYSTEN/INIT. The 
initializer is brought into memory by the Clear/Start code 
contained on the cassettee The second operation is the execution 
of some code in the NCPe contained in Page Zero» Segment Gne of 
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the NCP*s code file. 


At the completion of the initializer» memory will be formatted as 
shown in Figure 4022 Permanently allocated areas will be tocated 
at each end of memory. Linked memory will consist of four tinks 
only» The processor is then passed to the MCP*s code segment for 
completion of the Clear/Start operation. Upon completion of the 
HCP code» Linked smemory will be formatted as shown in Figure 4.3. 
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1 GISM0 CODE 1 


i MICRO MCP DATA SPACE i 


! MCP RUN STRUCTURE NUCLEUS i 


1 
i 
i 
A 


| 
Linked 
Meaory 
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j 
I 
1 
i 
4 
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ADDRESS ZERO 


; 1UTHLI 
In---1 SDL INTERPRETER. I--~~1 
1 ML I ! 
| ote nnnnn cece ne sernnceneneness=|] 
1 ' 
/ / 
/ / 
I---=1 i 
iM | i 
 latahelattatatatatatatetatataetatetatatatetatatateeateatel | 


{ MCP SEGMENT Or1 i 


Jews ww es am j 1 


1 LiMi i ML of 1 


mmm > | Snes Ss eS See eM See ee eee | 


I NCP SEGMENT 0-0 1 


1 CHIP ERROR TABLE 1 


i COLD/START VARIABLES ! 


1 INTERPRETER DICTIONARY 1 


1 MCP SEGMENT & PAGE DICTIONARY 1 


] scene ee weet ewes ee we eee ee eee |} 


1 MCP STACKS a | 


MAXIMUM ADDRESS 


See Note 1 


Figure 422 Memory Format After Initialization. 
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Eigure 422 Notes 


i. 


"UTNL™ and “"LIML™ are acronyms for upper and tower 
terminating memory tinks-. These two links have a size fielid 
of zero anda type field which denotes a terminating memory 
link. The upper link has a forward pointer of @FFFFFFas the 
tower fink has a backward pointer of @FFFFFFa.- The tinks are 
used to mark the boundaries of linked memory for the memory 
aliocation rowtines» Memory aliocated by these routines will 
atways lie between these two Linkse 


It is possiblese during the initialization procedure» for the 
operator to specify 4a maximum S~memory address that is less 
than the actual maxiaum address of memory on the system. 
When this is done» a proportionate amount of mewory is 
reserved at the location showne This memory is» in effect» 
deleted from the system. Memory may also be deleted via 
certain keyboard instructions avaitable to the operator. In 
the tatter cases the deteted memory may Lie at almost any 
address in the system. 
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1 | 1 uli | 
i----1 SDL INTERPRETER 1I------1 
IML 1 i 
1 BREE BEDS DVB esasnaseanmnnm wmweaes wwe oom | 
j PORT/CHANNEL TABLE> 1 
f----1 SPO VARIABLES AND BUFFER 1 
aM d i 
| otras ren seen ene ce een en nn n- nnn] 
i IQAT» TAPE PAUSE AND 1 
f----1 TAPE LOCK DESCRIPTORS 4 
ioMt t i 
' ADDITEONAL PORT/CHANNEL | 
jroo TABLE 1 
1m 1 
| orn en een nnn en eee e ecco ans] 
1 QUEUE DISK TEMPLATE ! 
1----1 i 
1 ML I 1 
[o-90------- wen eee nnn en ee nen ee ==] 
i MICRO MCP SEGMENT 1 
I----1 DICTIONARY 1 
IML 1 1 
Jeter nn nee cern en ne ee een een ne een] 
1 SOL INTERPRETER SEGMENT 1 
1----1 DICTIONARY i 
imu 1 
| om tan on er nnn nn nn nn ce nnn en nee] 
1 ERD AREA { 
joo") 1 
4oML 1 1 


/ See Note 1 fA 

/ / - 
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FENCE LOCATION © == === Se = Se eS ee ey 

j i 

[eere==) 1 
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Figure 4.23 Linked Memory Format After Clear/Start 
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Eigure 423 Notes 


1. Thoagh nothing is shown as present in figure 423 between the 
SOL. Interpreter Segment Dictionary and the Lower Terminating 
Memory Links this area wilt typically be filled with MCP code 
segments at the completion of the Clear/Start operation. 


2° The purpose of the fence shown in figure 4.3 was discussed 
previously» The tocation of the fence is retained in the mCP 
stacksSe It is not necessary to reserve any memory at ali at 
the fence Locations 


MEMORY REQUIREMENTS 


The memory that will be required to execute a given program or 
set of programs is composed of four components. There are the 
static requirements of the operating system» the dynamic 
requirements of the operating system» the static requirements of 
the program and the dynamic requirements of the programs. 


Static requirements are composed of the data spaces necessary to 
operate the system and the programs Once the static requirements 
are established» they typicaliy do not change» For exampte» once 
a program has ali of its files open» the memory required for the 
File Information Blocks and the buffers remain fixed until the 
files are closed. In the case of the MCP» once the system is 
Clear/Started» the static requirements remain fixed until the 
system is Clear/Started againe 


Dynamic requirements are exclusively code seqments. Assuming 
that a working set of the code segments cf a program is 
establisheds the dynamic requirements for that program wilt then 
be the total amount of memory that is required to contain the 
code segments that are a part of the working set. The operating 
system*s working set depends» of course» upon the communicate 
operators that are issued by the program in its own working seat. 


OPERATING SYSTEM STATIC REQUIREMENTS 


Those items shown in figures 4.2 and 423 comprise the static 
memory requirements of the operating system. Each item will now. 
be discussed and a means of datermining the amount of memory 
required by the item will be presented. The nuserical vatues 
presented herein apply to the 920 version of the MCP only. 
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Stacks 


The stacks used by the MCP with always reside at location 
zero in S“mesory» For each released version of the MCP» the 
stacks witt be of a fixed size» regardless of the machine 
configurations The stacks require roughly 349416 bits or 
4302 bytes. 


Page Dictionary and Segment Zero Dictionary 


These two items may never be overlaid and are maintained in 
memory immediately above the MCP stackse They wilt also be 
of a fixed size for each released version of the MCP. The 
10.0 version of the MCP code is divided into thirty-four 
segment pages and Page Zero contains thirteen segments. Each 
entry consists of a system descriptor» which requires 80 bits 
or 10 bytes» For the 10.0 version of the MCPs this item 
requires 3760 bits or 470 bytes of memory. 


Interpreter Dictionary 


An Interpreter Dictionary entry requires 224 bits or 28 
by tes. The number of interpreters that may be used on a 
system at any given time» and hence the number of entries 
atlowed in the Interpreter Dictionary» may be specified by 


the user to be any vatue between 3 and 31. {If the user does 
not specify this number» the Cold/Start routine will set this 
value to sSixe The memory required for the {Interpreter 


Dictionary may be calicutated by multiplying the nuaber of 
interpreters allowed by the size of one entrye 


Coitd/start Variables 


The variables contained in this area are originally set by 
the Cotd/Start routine.» Hany of them may be changed by the 


operatore The memory aliocated for their storage may not be 
changed. It will atso be a constant vatue for each version 
of the operating system. For the 10.0 versions the memory 


required is 2256 bits or 282 bytese 


Chip Error Tabte 


This area is atiocated on 81800 and B1900 series machines 
onty.»~ On ali other machines» no memory is required for this 
item. On the B1800 and 61900» the area is used to store the 
addresses of memory tocations which are experiencing 
correctable memory parity errorse The size of the area in 
bits may be caicutated by 40 plus €32 times the anaumber of 
entries atiowed in the tabie). The operator may specify the 
number of entries the table should contain. The default 
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value for the number of entries will be one entry per 16K 
bytes of S~memory on the systems 


MCP Code in Page Zero» Segment Zero 


This code segment is normally referred to as “Segment. Zero* 
and the size of the segment is a constant for each released 
version of the MCP. This is the only NCP code segment which 
dees not require a memory link» since it is outside of linked 
memory » The code segment requires roughly 532490 bits or 
6636 bytes of memorye 


Upper and Lower Terminating Memory Links 
In the 10.90 verson of the softwares a menory link requires 
187 bits of memory. These two then require 374 bits or. 47 
bytes. 

SDL Interpreter 
The sizes of the ‘SDL interpreters presented here are for 


reference ontye Accurate size figures and figures for the 
various segments of the interpreters are provided in the 


appropriate product specification.» Segment Zero of the 
$*Processor version of the SDL Interpreter requires 81656 
by tese The same segment of the M-Processor version requires. 


8024 bytese 


MCP Run Structure Nucteus 


The MCP requires a Run Structure Nucleus field as does every 
other program which executes on the system. For the 9.0 
version of the softwares 2386 bits or 298 bytes are allocated 
for this field. 


Micro MCP Data Space 


Currently» 1249 bits or 156 bytes are allocated for this 
spacee This requirement is a constant and is not dependent 
upon machine configuration nor system options selected» but a 
dual processor configuration will require two such spaces» 


GISMO Code 
GISM0O is not segmented. Selected portions of the GISNO code 
are "discarded" by the Initialization routine if they are not 


required on a given system configuration with a given set of 
system options selected. The amount of memory that will be 
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required to contain GiIsmoe must therefore always be 
calculated. 


The Main Biock of GI5M0 requires 5500 bytes of memorye No 
memory link is required. The amounts of memory shown in the 
following tabte should be added if the condition specified is 
true. 

System equipped with Memory Base 5 104 bytes 
Processor is a B1i830 436 bytes 
Processor is 81720 series 540 bytes 
Processor is 81860 series 642 bytes 
Processor is Dual Bi8Xx 1070 bytes 
Reference address check option set 138 bytes 
Thrashing detection option set 142 bytes 
Prioritized memory management option set 364 bytes 
TOUT option set. . 100 bytes 

In the List above» the cassette device on the processor 


console is not considered a peripheral. Neither the cassette 
peripheral segment nor the magnetic tape or cassette segment 
should be added due to the consote cassette. 


The controi exchanges segaent should be added when the system 
is equipped with two or more disk or tape controls and the 
controls address the same peripheral units» High-speed 
controls. are ail disk pack controls and any controls which 
address phase~encoded tape drives. Under no conditions is it 
necessary to add any GISMO code segment more than oncee The 
Duait Processor segment and the B1860 segment must both  ~be 
added if the system is a duai processor version. 


Firmware Trace Space 


This area is allocated onty when running with trace versions 
of the SOL Interpreter. It should never be allocated in a 
customer's machinee It requires 12440 bits. 


Interrupt Queue 


Since interrupts occur asynchronously on the B1000 system» 
they must be queued until they can be handied by the 
appropriate operating system routines. Bne entry in the 
interrupt queue requires thirty~"six bitse Forty-two bits are 
required for pointers and counters. The number of entries 
which may be queued on a given system depends upon the amount 
of memory on the system. The number of entries that wilt be 
alfocated may be determined from the foittowing table. 


S“Memory on System Entries 
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Less than 64K bytes . 16 
At least 64K bytes but less than 96K bytes 20 
At least 96K bytes but less than 128K bytes 25 
126K bytes or more 30 


The smallest amount of memory that witl be aitocated for the 
interrupt queue is then (42 + (16 X 36) or 618 bits. The 
largest amount is 1122 bits.» 7 


GISMO Data Space 


The GISMO data space is a work area required by GISMO. It is 
a fixed size and amounts to 376 bits. 


DCPU DATA SPACE 


This is atso a work areas It is required on all dual 
precessor machines and requires 350 bits. 


Looking now at figure 423» the MCP» prior to completing the 
Clear/Start operations will allocate space for those additional 
items shown on the figure. The Location of the “Fence™ is not 
important to the discussion of the memory requirements of the 
MOP.» The fence is merely a means of guaranteeing that the MCP 
wiil adways find space for its own purposes when such space is 
needed The system would be forced to halt if the MCP could not 
find the space required. 


Ali of the items shown in figure 443 reside in linked memory. 
One memory Link €187 bits?) is required to describe each of the 
items in figure 4.3 


Extended Result Descriptor Area 


Gne extended result descriptors [/0 descriptor and buffer is 
required for each ON head-perwtrack disk control and for each 
disk pack spindie on the systems Each descriptor and its 
associated buffer requires 256 bits. This requirement 
applies to att disk pack drives interfaced to the 81000 
system but not to cartridge drives» The msenory required» in 
bits» may be calcutated by 256 X €5N controls + disk pack 
spindles) © memory Link. 
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SDL Interpreter Segment Dictionary 


The segment dictionary of the SDL Interpreter is considered 
nonmoverlayables Since it contains a descriptor for segment 
zero of the interpreter which must be nonwrovertayable to 
execute segment zero of the MCP. The size of this areas» in 
bits» may be calculated by 64 plus (80 times the number of 
segments which comprise the interpreter) plus the space 
required for one memory tink» The SOL Interpreter contains 6 
segmentss plus Segment Zero. 


Micro NCP Segment Dictionary 


This segment dictionary is aiso considered non-overlayable. 
Its size may be calculated in the same manner as the size of 
the SDL Interpreter segment dictionary» 64 pius €80 times the 
number of segments) plus space for one senmory§ Linke The 
Micro MCP contains 18 segmentse plus Segment Zero. The 
segment dictionary therefore requires 190 bytes. 


Queue Disk Template 


The NCP reserves 500 segments of system disk for its own 
temporary wus@e The address of this reserved area of disk» 
known as Queue Disk» is stored in the memory area known as 
the Queue Disk. Templates. This memory area will also contain 
one bit to denote the availabitity of each of the 500 
segments» a 24-bit fieid which will be used to store the 
memory address of the next Queue Disk Template if an 
additionai 500 segments must be allocated and a i28~bit field 
knoun as the Communicate Splitter Maske This Latter field is 
used to determine which communicate operations may be handied 
by the Micro NCP. The size of the initial Queue Disk 
Template field is therefore» 5004364244123 or 688 bits. 
Additional Queue Disk Template fiedds» if required» wild 
occupy S560~bit areas» One memory Link is required on each 
Queue Disk Tesuplate allocated. 


Additional Port/Channet Tables 


The MCP and GISMO comaunicate in a number of ways. One such 
way is the Port/Channel table. Dne Port/Channel tabte is 
allocated with the SPO variables and buffer at the high end 
of linked memory. If the system is equipped with multictine 
controls» an additional Port/Channel table wilt be required 
for each one. A Port/Channel table requires 768 bits of 
memory plus the space required for one memory Links 
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IOAT €I/0 Assignment Table) 


Several items are grouped together in the space reserved for 
the IOATj The IGAT itself requires one entry of 512 bits for 
each peripheral unit connected to the system with the 
exception of the SPO. Each disk pack spindle is considered a 


peripheral unit. Head~per-track disk is note Data 
comeunications devices are not considered peripherai units 
for the purpose of calculating IOAT sizes» but each 


singlerline control connected to the system requires one [GAT 
entrys One "Pause" descriptors requiring 96 bits of memory» 
is required for each tape controle» cassette control. and 
MTC-2/NTC"4 exchange on the system. One "Lock" descriptor» 
requiring 168 bits of memorys is required for each tape and 
cassette unit connected to the systeme- One 1/0 descriptor of 
248 bits. is required if any number of filexidisk units are 
cannected to the systea. One memory tink is required to 
describe the area containing these items. 


Port/Channel Table» SPO Variables and Buffer 


Information which the MCP needs to perfora its function which 
is primarily concerned with the system SPO but also includes 
inforsation on other aspects of the system is maintained in 
the area known as SPO Variables. This information requires 
1351 bits of memory. The Port/Channet table requires 768 
bits and the SPO buffer requires 560 bitss for a total of 
2679 bits» OGne memory link is required to describe the area. 


~QPERATING SYSTEM DYNAMIC REQUIREMENTS 


The operating system's dynamic memory requirements are determined 
solely by the size of the code segment which performs the 
functions requested by the user in the working set of his 
programs In determining this requirement» it is necessary to 
know what the program in question is doinge White programs coutd 
be and are written which have file open and close operations as a 
part of their working set» this is not normally the casee The 
vast majority of programs request only those functions which are 
micro~coded and inciuded in the Micro NCP in their working set 
codee This statement is not true for programs which use DMS. 


This document will not present the memory requirements for 
programs which use DMS. This information witt probably be added 
at some point in the futures but for the present» oanly the code 
segment sizes for operations believed to be common and exclusive 
of DMS operations will be presented. 


4-21 


B1G00 MCP MANUAL 
MARK 10.0 


The List below presents a brief description of the function and 
the memory requirement for each of the Micro NCP segments. 


SEGMENTeZERG = 2506 Bytes 


Segment Zero of the Micro MCP is always required in mesory 
when programs are executing» 


‘SERIAL = 1960 Bytes 


This code segment handles reads and writes on serial files 

that are opened input or output but not in any combination 
form» such as inputoutpute Also» some files assigned to 
‘data recorders may not require this segmente 


SEQUENTIAL = 762 Bytes 
This code segment handies reads and writes on sequential disk 
files that are opened input“outputs 

RANDOM ~ 944 Bytes 
This code segment handies reads» writes and seeks on code 
segments whose access mode is randoms This code segment is 
required for att random disk files» even if the access sa,ode 
is delayed random. 

COMP.~WAIT - 1136 Bytes 
This code segment is required to handie complex wait 
communicate operations.» Atl data communications handters 


generated by the NDL compiter require the complex wait code 
to be presente 


DATA»RECOR - 344 Bytes 
This code segment is required to handle reads and writes on 
files which are assigned to data recorders and which are 
opened inputoutput or input with stacker selection 
capabilities requested. 

HI«PRIeAND ~- 1292 Bytes 


This code segment is required to handte att comaunicate 
operations on files which are assigned to reader~sorters.. 
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QUEVE.~READ ~- 856 Bytes 


This code segment handles read and write operations on 
queues. Please refer to the paragraph at the end of this 


POQON.GOM ~ 2674 Bytes 


CPut Queue Message-Get Queue Message). This code segment 
handles reads and writes on files assigned to queues and to 
remote filese Piease refer to the paragraph at the end of 


REMOTE HRI =~ 2300 Bytes 
This code segment is required to handle writes on files 
assigned to remote files. Please refer to the paragraph at 
the end of this List. 

REMOTE -REA = 2890 Bytes 
This code segment handies reads on files assigned to remote 
files. It is also required to handie many NDL/MACRO 
communicates Piease refer to the paragraph at the end of 
this list. 

DC»INITIAT - 410 Bytes 
This code segment handles the OC.~INITIATE.10 communicate 
operation.» This comaunicate is issued by att data 
communications handters generated by the NDL compiter. 

MESSAGE.»CO = 208 Bytes 
This code segment is required to handle the message count 
communicate operator» aiso issued by ali data communications 
handlers generated by the NDL compilere 

VARTABLE~L = 412 Bytes 
This code segment handles read and write operations on tape 


and disk files which use variabierlength records. It is 
required in addition to the SERIAL code segmente 
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EMULATOR.T = 508 Bytes 


This: code segment is required to handle communicate 
operations requested by any emutator interpreter on files 
assigned to tape. 


DELAYED~RA =~ 592 Bytes 


This code segments in addition to the random code segments is 
required to handle readss writes and seeks on files whose 
access type is delayed randoa. Emulator disk files are in 
this category. 


INDEXEDeSE = 3920 Bytes 


This seqment is used for I/0 operations on Indexed Sequential 
files» first introduced in the 9.0 version of the software 
and described in the section of the document on the I/0 
Subsysten. 


RELATIVE =~ 3638 Bytes 


This segment is used for I/G operations performed on Relative 
fides» also described in the I/0 Subsystem sectione 


Ipc.CODE - 568 Bytes 


This. segment is used to perfora Inter-Process comsunications 
apart of the ANSI "74 COBOL implementation first included in 
the 9.0 software. 


All code necessary to handle queues» resote files» the 
DC»INITIATE-I10 communicate and the. MESSAGE-COUNT communicate are 
included in the Micro MCP. Microcoding these functions resulted 
in some substantial performance improvements for most data 
communications applications. There are severat reasons for the 
japrovements the most obvious being the greater efficiency of the 
code. Another factor is that a minimat amount of state 
information must be saved uhen communicating with the Micro MCP. 


A third factor is the elimination of the "bottieneck”™ problem» as 
it has come to be cailed» for data cosnunications applications. 
This probtem arises from the fact that MCPIT is a flat structure 
and is capable of performing one thing at a time onlye In other 
words» once the MCP begins performing an open request § for 
examples it can do nothing etise until it comptetes the open. An 
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opens of courses requires many accesses to the disk subsystem and 
the NCP must wait on the conptletion of each one. Normail~state 
programs are free to execute white the MCP is waiting on each 
access» provided they do not request an MCP service which aust be 
handied by MCPII. 


Consequently» user prograss may now use the queue subsystem and 
the other items mentioned above while MCPII is servicing another 


request for other userse In previous releases» these same user 
programs had to wait until the MCP completed servicing the 
request it was working on at the time. Unfortunatety» however » 


ali requests for functions in the queue subsystem are not handted 
by the Micro~MCP,. Many of them» and possibly att of them» may 
stiti be handied by MNCPII. 


Ali memory management functions are stidil handled by SDL code in 
NCPII. Any queue request which involves memory management will 
therefore have to be handled by MCPITI. This wild most often 
occur in situations where the available memory on a system is 


dinited. Queue buffers may be written to disk by MCPII» and 
hence removed from memory» whenever the MCP needs space _ for 
something else. This will cause MCPII to be invoked when a 


program attempts to read a queue entry from that buffer. 


Further» if a producer of queue entries filits an entire buffer 
before the consumer can empty ite anew memory buffer wilt be 
required. MCPII wiil be invoked to accomplish the allocation. 
Unfortunatelyr in both of these instances» the entire working set 
of Micro"MCP queue handling segments wili be brought into memory» 
only to determine that SDL MCP segments are ready required. This 
can result in substantial performance degradations particularity 
on systems where available memory is limited. 


The situation described can be avoided» of course» by insuring 
that the consumer of queue entries removes them from the queue at 
the same rate that the producer enters them. Since it is onty 
rarely possible for the programmer to insure that synchronization 
existse a system option has also been provided in the 6-1 release 
which will insure that ail queue requests are handled exclusively 
by the SDL NCPe By setting the options the user may insure that 
performance does not degrade when going to the 6.1 release» as a 
result of the microcoded quaue implementation» though he will 
receive no benefit from it at ald. 


Six new segments were added to the MicromMCP to accomodate’ the 
data communications facilities in the 6.1 release. The new 
segments are QUEUE.-READ through MESSAGE j»COUNT inclusively. 
Typicaliy>» data communication applications which use a handler 
program generated by the NOL compiler shoutld consider all six 
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segments to be a part of their working set» though only the first 
four of the six are concerned with the queue inplementation. The 
MESSAGE.-COUNT segment is invoked by the communicate operator of 
the same name and is used to determine whether cr not a message 
exists in the queues- The DC.INITIATE.10 segment is also invoked 
by the communicate operator of the same name and should always be 
considered a part of the working set for any data communications 
applications» 


PROGRAM=DEPENDENT SIATIC REQUIREMENTS 


The static memory requirements of a programs that memory which is 
required for everything except the program*s code» may be divided 
into two classes. Three items which are required are fixed in 
size and the user has no control over them. The user actuaily 
has Little control over sany of the static requirements» though 
there are some items which he may cause to varye Items in the 
datter category are referred to as conditional requirements. 


The fixed requirements of the Program Static Nemsory are composed 
of three componentse These are listed below. 
Run Structure Nucleus 
This is a table of inforaation constructed by the MCP when 
the program reaches BOJ- [t is a fixed size of 2386 bits. 
Interpreter Segment Zero 
The size of Segment Zero» the nonwtoverlayable segment» of the 
Interpreter being used must be determined and added. Space 
for one memory tink gust be inctuded. 
Interpreter Segment Dictonary 
The number of segments in the Interpreter must be determined. 
The space required for its segment dictionary is then ten 


bytes times the nuaber of segments plus space for one memory 
dink. €10 X number of segments) # memory tinke 


The fodlowing are the conditional items which must be included in 
the calculation of Prograaw Dependent Static Requirements. 


Program Code Segment Dictionary 


The number of code segments which comprise the program may be 
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deterzined from the compiier listing of the programs Code 
segment dictionary space in bytes is then determined by (10 X 
number of segments) # memory Link» 


Data Dictionary 


The number of data segments used by the program is known to 
the programmer and is available from the compiler Listing. 
The space for the data dictionary in bytes is calculated by 
(10 X number of data segments). No memory link is required. 


Base~Limit Area Calso known as Program Run Structure) 
This number is.readily available from the compiter tListing~ 
It is the total data space required by the program (between 


Base and Limit Registers). Space for one memory Link must be 
added. . 


Fide Dictionary 
There is one entry in the file dictionary for each file 
declared in the program» regardiess of whether it is aver 
used or note File Dictionary space is given by €10 X number 
of files declared). No memory tink is required. 


File Information Block CFIB) Space 


This may be cadicutated in bits by: 


1048 x Number of MICR Files open plus 

79d x Number of Printer Files open plus 

605 x Number of Remote Files open plus 

796 x Number of Tape Files open plus 

1048 x Number of Disk Fites open plus 

433 x Number of Queue Files open plus 
1048 x Number of ati other files open at the time. 


FIB Memory Links 


One memory Link is required for each file that is open. 


Total Buffer Space 


The nusber of and the size of the buffer areas associated 
with each file that is open may be determined from a compiier 
listing. This size should be totaled and added. If the code 
file on disk has been modified» however» the size given on 
the listing may be incorrects True buffer size may be 
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determined through an MCP keyboard instruction. CRefer to 
B1i000 Software Gperational Guide.) 

I/G Descriptors 
There is one I/0 descriptor» which requires 272 bits of 
Spaces for each buffer in each file that is open. 

Disk File Headers 


Disk file headers are maintained» either in memory or on 


disk» for ait disk files that are open. If the file is 
processed in arandom access mode» the header is maintained 
in memorye Otherwise» the header is stored on disk and 


brought into semory when new disk areas are attocated. Each 
header wilt require 530 bits plus 36 bits for each area 
requested by the file dectarations regardless of whether of 
not the area is allocated» pius space for one memory Links 
This area is required onty when the header is in memory. 


Header Dictionaries 


Disk file headers are addressed by the MCP through 
dictionaries. These dictionaries are segmented. One segment 
contains space for ten dictionary entriese Each dictionary 
entry is a system descriptor and requires 8C bits of memory. 
The space required for header dictionaries may be catculated 
by €800 # memory tink)? X CCdisk files open “OD 10) #+ 13 bits. 


PROGRAMTDEPENDENT DYNANIC REQUIREMENTS 


To determine the working set of segments for any program one must 
know where 2a program spends its tise or its “main Line” of 
procedure cails. The corresponding segment sizes must then be 
added up for this main sequence. Segment sizes can be obtained 
from compiler Listingse For RPG programs» all code segments must 
be included in the working set. For ati other programs the 
compiters produce a list of code segments and sizese Then the 
working set segments should be tisted and totalled. Ail segment 
sizes should have 20 bytes added to account for the size of an 
associated memory Link» 


As previously discussed» if any interpreter segments are used by 
the program» these must also be included in the total. 


4-28 
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MINEMORY MANAGENENT 


The function of M-memory management is to best manage the 
available controt memory (N-memory) in a dynamicaliy changing 
environmente There are four events which are abie to affect the 
system"*s demand for M-memory by the introduction or removal of 
interpreters: 


ROLLIN 
ROLLOUT 


Upon the occurrence of any of theses if the interpreter set 
changes» the new demands wilt be evaluated and M~memory 
reailocated. 


One of two allocation schemes will be employed: 


DISTRIBUTION 


This method distributes the available M-memory statically among 
the active interpreters. The size of each portion depends on the 
interpreter*s needs» and the availabie aspount of M=memory>» The 
portion of the interpreter which is not able to be placed in 
M-mesmory remains in S~menorye As the number of active 
interpreters increasesr this addocation scheme remains in effect 
until further dispersion of M-memory would result in a severe 
performance degradation. When this threshoid is reached» the 
second aliocation scheme is put into ef fect. 


CONTENTION 


This method dynamically shares M-memory» in the form of n fixed 
size pages» among greater than n interpreters contending for 
these pages. When an interpreter succeeds in capturing a page of 
M-memory» the Llowrorder portion of the interpreter will be copied 


into the page. from S“menory-. However» when the page is 
rewcaptured by another interpreter» since there is no mechanism 
for transferring information from M “memory to S“memory» the 
information in that page will. be tloste Hence» all active 


interpreters must be entirety in S“menorye 


DETAILED DESCRIPTION 


1. When a new interpreter is to be brought into memory» the 


Ze 
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procedure “MeIN.M.»OUT*® is called. This may be catled either 
from B80J» E0OJ» ROLL-IN» or ROLL-OUT. The last entry tin the 
interpreter dictionary is first stored in “DIC.LAST.LOC™. 
Then the interpreter dictionary is searched for entries 
whose usercount is equal to zero (thus no longer in use). 
These entries are deteted by calling "M-CLEAROQUT”.« 


The previous allocation method is then stored. If there is 
no MeMEMORY on the system (B1I710 series)» then the procedure 
"NOM" is callede NGeM examines in turns each entry in the 
interpreter dictionary to ascertain if it is in SeMEMORY or 
not» and if nots the procedure "D.7T025" is called to bring 
in the interpreter from disk» The presence bit is then set 


Calthough the system has no M»eMEMORY)» and a pseudo MeMEMORY 


address is calculated and stored in “1D.N»ADDR”. NO .M then 
exits to M»IN»M.OUT and thence to the procedure which catlted 


Assuming that MeMEMORY does exist» the total minimum number 
of NeMEMORY pages required for ali interpreters is added to 
that required for CSM» then this total number of pages is 
compared to the total number of pages of MeMEMORY available 
on the systen. 


If the total number of pages required is greater than those 
availabies then the contention method is invokeds otherwise 
the distribution method is invoked. Tae contention method 
witl be discussed first. For the distribution method» 
proceed to step 6. 


The contention method caits the procedure "“CNINeSETUP". 
CNINeSETUP first checks to sea if the pages remaining after 
CS ais allocated is tess than 2e and if so» then all the 
interpreters wiil be contending for the remaining page» 
including SDL» and the procedure contention is catied 
(proceed to step 3). If the number of remaining pages after 
aifocating CSM is not tess than 2% then this nuaber of pages 


is stored in “M»NUMNBER.PAGES*. The SDL interpreter is 
assigned a pages» plus any fraction of a page which may be 
left overs This may occur if CSM does not occupy exactly a 


full page» normally 1024 words». Next» the number of active 
interpreters is counted and this number compared = against 
MeNUMBERs PAGES. If MeNUMBERSPAGES is greater than or equal 
to the number of active interpreters» then the distribution 
method is calted (proceed to step 63. (This could be caused 
by an interpreter with a very large minimum requirement.) 


The procedure contention first ascertains if the SDL 
interpreter is partially resident in SeMEMORY» and either 
MeNUMBER»PAGES is equat to l» or the portion of the SDL 
interpreter in MsMEMORY is greater than the size aldocated 
for SDL. If so» then the procedure “"HIL.~T00eS" is called» 


he 


De 
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else proceed to step 4. HIL.~T0-5 saves the current S»MEMORY 
address of the SOL interpreter»s and stores the disk address 
of the SDL interpreter in the interpreter dictionary entry 
for SDL. The procedure “D.TGe5" is then catled to bring in 
the interpreter from disk. D»~T0-5 Looks for memory for the 
interpreters» makes the found address mod. 16>» reads the 
interpreter into memory and marks the interpreter dictionary 
entry present. If sufficient memory space was not found» 
then the previous (partial? SOL interpreter is restored in 
SeMEMORY* and adil procedures exited» returning ali zeros to 
the procedure which catled MoINeM.OUT. Otherwises the new 
copy Ccomplete) is marked not present in M.MEMORY and the 
memory space of the oftd partial copy marked available. 
HIL-eTOe5 now exits» returning to the contention procedure 
Cproceed to step 5). 


If neither *MeNUMBERjPAGES" is equal to 1 nor the portion of 
the SDL interpreter in M.MEMORY is greater than that 
allocated for SDL» and if the portion of the SDL interpreter 
in M»MEMORY is less than that ailoweds then the procedure 
"LK-OUT»MOR™ is calded to move more of the SDL interpreter 
from SeMEMORY to MeMEMORY «= 


The procedure "MeCLEAROUT*™ is then cadiled to clear out of 
the interpreter dictionary allt partiality resident 
interpreterse with the exception of SDL. Each entry in the 
interpreter dictionary is then in turn examined» and passed 
through the procedure "CNIN»LODADR”™ until atl entries are 
examined» at which time contention is exited to MeINM.OUT 
Cproceed to step 10). 


The function of the procedure "CNIN.LOADR™ is to toad 
interpreters either from disk to S.MENORY> and/or from 
SeMEMORY to M.MEMORY. It first examines the interpreter 
dictionary entry to determine whether the interpreter is on 
disk or in S»MEMORY. If it is not in S.MEMORY> then the 
procedure “"DeTGeS" is caited to bring the interpreter in 
from disk. If sufficient memory. space is not found» then 
DeTQ2S exits through all procedures» returning all zeros to 
the procedure which catlied M.INM.OUT. "ID .N»ADDR*™ and 
"IDe-TOPM”" are caicuiated. Each interpreter is set up for 
one page of memorye If there is available M.MEMORY teft>» 
then the page is overlayed from S.eMEMORY to WNeMEMORY 
Cproceed to step 10). 


If the totat number of pages required is not greater than 
those availabie»s then the distribution method is invoked» 
and the procedure “REDISTRIBUTION™ calied. The procedure 
redistribution catcudates whether the amount of available 
M»MEMORY is exactly of a size required to house the mininuan 
requirements of ali interpreters and CS. If so» then the 
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procedure “NeGRINDER™ is called passing a value of ti. 
(Proceed to step 7). 


Otherwise» the total amount of memory required to house the 
maximum requirements of atid interpreters and CSM is 
calculated and compared against the totat amount of MeMENORY 
available» and if tess than or. equal to the amount of 
MeMEMORY available» then the procedure M.GRINDER is cadfed>r 
passing a value (field WHICH ) of zero (proceed to step 73. 


{f neither of the above conditions is met (that is» neither 
the minimum nor the maximum of alt interpreters will fit in 
MNeoNEMORY) then the procedure “DISTRIBUTE” is calledr passing 
a value (field WUH) of zero. The procedure distribute 
stores the maximum available MeMEMORYs amount required for 
CSM» then if HUH = 0» it initially assigns each interpreter 
its minimum required space» increments each one in turn by 
one pagee until aii availabie M.MEMORY is allocated.» If HUH 
= Il» each interpreter*®s minimum is assumed to be zeros then 
incremented by ane page until ail available M-MEMORY is 
ailocated. The procedure M.GRINDER is then called» passing 
@ value Cfield WHICH) of 2. 


The main function of M»GRINDER is to reallocate MeMEMORY one 
of three different ways» depending on the values of “WHICTH". 
MeGRINDER examines each interpreter dictionary entry in 
turns After having examined aii interpreters» if there is 
still some MeMEMGRY remaining» then proceed to step 9» 
otherwise proceed to step 10. 


If the entry being examined is not in MeMEMORYs» or the page 
being examined is not the current M»MEMORY page» then 
proceed to step 9-» Otherwise» if the size of this page in 
MeMEMORY is not the size it should bes» proceed to step 8. 


If this MeNEMORY page is the correct sizes and if the 
interpreter is either partially resident in S.MEMORY or if 
the total tength of the interpreter is less than or equal to 
the amount of this interpreter currently in MeMEMORY Cieee» 
the interpreter is entirely in M.MEMORY)3 and this 
interpreter is not in SeMEMORY»s» then proceed to step 9e 


Otherwise (that ise the interpreter is entirely resident in 
5 »eMEMORY>» so the portion of SeMENGRY which was copied to 
MeMEMORY must be returned)» the interpreter is saarked = as 
partiattly resident in S.MEMORY. If the total length of the 
interpreter is dess than or. equal to the amount of the 
interpreter currently in M»MENORY>» then the procedure 
"ALLeINeM" is catled to return the entire SeMEMORY space for 
this interpreter. Otherwise» the procedure “"LK~OUT.~MEM” is 
called to return the S-eMEMORY space corresponding to that 
portion of the interpreter which has been. copied into 
MeMEMORY. 


574 


9 
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{If the amount of the interpreter in Me~MNEMORY is tess than 
the amount allocated in MeMEMORY for this interpreters then 
the procedure "“LKe-OUT~MOR" is calied to copy more of the 
interpreter from 5SeMENORY to MsaNENORY. 


If this point is reachede then the appropriate interpreter 
must be brought in from diske. 


The procedure “"M.CLEAROUT" is caited to clear out alia 
partial interpreters from the interpreter dictionary Cwith 
the exception of the SDL interpreter and atready fitted 
interpreters). 


If the current entry in the interpreter dictionary is SDL» 
then the procedure HIL~T0.-S is catiled Crefer to step 3. for 
the functions of HIL»T0.5)-~ If sufficient memory space is 
not found in HIL.~TO.5» then exit through all procedures 
passing a value of ali zeros to the procedure which catled 
MeINeMsOUTe? Next» each entry in the interpreter dictionary 
is examined in turns and if present in SeMEMNORY but not in 
NeMEMGRYs then the procedure “5.eT0eM" is called to overlay 
the appropriate page from SeMEMNORY to MeMEMORY> and to 
return either the entire S.MEMORY space occupied by the 
interpreter or else to return only the portion overtaid. 
Each entry in the interpreter dictionary is once again 
examined in turns and if the presence bit is sete proceed to 


If the presence bit is not set» then the procedure D.T0.+5 is 
calted to bring in the interpreter from disk to memory 
Crefer to step 3 for aé description of 0D.T0.5). If 
suf ficient memory is not found in 0.70.5» then alt 
procedures are exited» passing a value of all zeros to the 
procedure which cailed M.-INM.OUT. 


The procedure 5.T0.M is then cailed Csee description above). 


At this points the aitlocation sethod Ceither distribution or 
contention) has been decided and executed» and control 
passed back to M.~IN..M.0UT. 


If the new allocation method chosen was successful» and if 
the new adfocation method is the same 2s the old one» 
proceed to step 11. If the new method is distribution 
Ctherefore» the old was contention)» then the procedure 
RELEASE»AeSEG is catled to mark the MCP segment REIN.~STATE 
available (reset save bit in the memory Link). If the new 
method is contentions then the procedure SAVE.»AeSEG is 
called to mark the MCP segment REIN-STATE saved Cset save 
bit in the memory Link). 


ile 
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If the value passes to MeGRINDER CWHICH) was 0 or 1. Then 
return from M.~GRINDER through redistributions to MeIN.M-OUT. 
If the vadiue passed to MeGRINDER CWHICH) was 2» then return 
from MeGRINDER through DISTRIBUTE to REDISTRIBUTION> to 
MeoINN2OUT and thence to the procedure which catied 
Me INeQMe BUT. 
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PROCESS (PROGRAM? MANAGEMENT 


Viewing the MCP as a manager of processes emphasizes its role in 
the management of job executions That part of the MCP concerned 
with such management may be tersed the “process conatrotier™. 
While the process controller is not a distinct wodule in the MCP» 
it is a convenient term to describe atl those distinct functions 
which» taken together» form a conceptual package.» Certain of 
these functions» namely "ROLLIN"» “ROLLOUT "» "CAUSE™» "HANG 
PROGRAM» are best understood within this context and will be 
discussed tn depth in this section. 


The actual execution of programs» the atlocation of processor 
tise to processes which are ready to execute and ares therefore» 
in the Ready Queue» is accomplished by micro code contained in 
GISMG known as the “Micro Scheduler”. The Micro Scheduler is a 
part of the process controller. The Micro Scheduter is 
responsible for the allocation of att processor time on ali 
processors which may be attached to the system. 


The process controller is driven by the occurrence of certain 
software events» called “soft events*» which can be identified 
and anticipated by the MCP. When a process submits a request to 
the MCP» the process may or may not be required to wait. If a 
wait is necessary», the MCP is able to anticipate the event upon 
which that process must wait. Thus the MEP can tabel the job as 
waiting for some “soft event"» suspend the job by placing it in 
the “watt queue"s» and continue to execute its other duties. When 
the soft event “happens"» the Nicro NCP can search the wait queue 
to discover the process marked waiting for the happening of that 
event. ; 


The “HANG PROGRAM” functions which places programs in the wait 
queues and the “CAUSE™ function» which takes prograas from the 
wait queue» are crucial. Both functions must be cognizant of the 
Same soft events. "HANG PROGRAM" is responsible for creating a 
unique bit string which will represent the soft event for a 
processes On the other end “CAUSE* must have the proper soft 
event generated for it» so that the waiting process can be 
lorated. 


The main asset of this method of process manipulation is to free 
the MCP from waiting for the completion of 1/0 operations. It is 
able to initiate a requested operation and to independently satch 
a soft eavent with its corresponding process at a future time when 
the operation has been compieted. 
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The process controltler receives inputs from two sources: an “I/0 
DEVICE* or a “CONTROL DEVICE”. Both may affect processes in the 
system. User demands upon the system are submitted through a 
control device which may accept only control language statementse 
On the Bi000» the supervisory printer CSP0) may only be used as a 
conatrot device. The card reader may be dynamicaliy assigned as a 
control device or an {/0 device. All other peripheral devices 
may be used as I/70 devices onty» In addition» a program may act 
as a controt device by sending a communicate to the MCP which 
contains a controt Language statement. See "PROGRAN 
COMMUNICATES". 


Control tlanguage statements» of direct interest to the process 
controller» may be divided into three categories: 


€1) Statements which generate a soft event Ce.gs» allow a 
suspended process become actives direct a process to a 
peripheral device) 


(2) Statements which cause job suspension 


C3) Statements which request job execution and provide alt § the 
appropriate parameters 


If the controt tanguage statement requested that a job be 
executeds the “Control Language Processor™ directs that the job 
be scheduled. Briefly» the scheduling function involves placing 
it in the "schedule queue” but aitocating no sachine resources. 
In the MCP outer itioop» the schedule queue is periodicaily 
checkeds and the first job in the queue is initialized. 


"Program Initialization” involves aliocating the machine 
resources and setting up the structures necessary for progran 
execution. Once the job has been initialized» it is placed in 
the “READY QUEUE" to await actual execution. 


Once a program has been initializede it wilt move in and out of 
six possible states during the course of its Life in the system: 


READY QUEUE 

COMMUNICATE QUEUE 

WAIT QUEUE 

NOT QUEVED» EXECUTING 

NOT QUEVED» COMMUNICATE BEING ANALYZED 
M COMMUNICATE QUEUE 
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The ready queve contains jobs which are ready to runs The 
communicate queue contains jobs which have requested some MCP 
function. The wait queue contains jobs which are waiting for the 
“happening of a "soft event. 


The queuing mechanism is managed as follows. Ali run structures 
are linked in memory by priority» A fietd in the run = structure 
nucileuse "RS 2Q2 IDENT» specifies the current state of the 
process. The first member of a queue can thus be found by 
searching the tinked dist of run structures until the proper 
value in RS.~Q-IDENT is found. 


A job waiting in the ready queue represents a demand for 
processor time upon the system. This queue is interrogated by 
the Micro Scheduter. If a job is found» the reinstate functions 
which is performed by the Micro Scheduler in GISMOe is called in 
preparation for turning the processor over to that job. Briefly» 
the reinstate function performs certain housekeeping duties and 
causes a processor to begin execution of that job. 


The program wiit execute until one of three things happen® 


(1) The program*s interpreter discovers an interrupt which 
reguires the MCP*s attentions 


C2) The program needs some MCP service performed before it can 
continue 


C39 The master processor instructs the stave to idle. 


In any case a communicate message is built in a fieid cattled 
RS»COMMUNICATEsMSGePTIR in the program's Run Structure Nucleus and 
controt is passed back to the Micro Scheduler. 


The contents of RSj«COMMUNICATE.NSGePTR» analyzed by the 
"communicate handtler™ in the Micro Scheduler» specifies what 
action is. to be taken upon the programe In the case of (Ci) 
above» the message witl simply contain a request to be put back 
in the ready queues (The Micro Scheduler then returns to its 
outer loop where it independently discovers the INTERRUPT.) 


A request for service (2) may or may not require that the prograr 


wait for the happening of some soft events If the request can 
immediately be serviced» the Micro Scheduler does so and places 
the job back in the ready queues If the program aust wait» 
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however» the “HANG PROGRAM*® function is caitled. 


"HANG PROGRAM™ puts the job in the wait queue and tabels it as 
waiting on the appropriate soft event. Depending on the reason 
for the wait» the program may or may not be "rotted out”. The 
"ROLLOUT" function witli copy ali but a centrai core of the 
program"s Run Structure Nucleus to disk. For a detaited 
discussion of these functions» see their respective sections 
belows 


The program wilt remain in the wait queue until the event upon 
which it was waiting has been "caused". The soft event upon 
which a job must wait may come from three basic sources: 


Ci) 7/0 interrupts 
C2) Controt tanguage statements 
C3) mcpe 


I/O interrupts are “hard events” which must be transformed into 
soft events before they may be associated with a processe A hard 
event is any asynchronous occurrence in the hardware of which the 
software must be cognizant. The occurence of such a hard event 
is usually manifested by a flag in the processor» The function 
of “I/0 COMPLETE" is to transfora those hard events of interest 
to a process into its corresponding soft evente 


Some control language statements will cause the control language 
processor to generate soft events. Such statements signify the 
happening of some event a process might be waiting for Ceege» 
PAX"™s PIL" > PUL" > *GO"» and “O0K*"). 


Other soft events are generated internally by the MCP. For. 
exampie» processes waiting on a no“menory condition or a parent 
program waiting for the termination of a nested program must be 
notified when they are able to resume processing.» The mCP 
generates such soft events. 


At the point when the soft event .has been generated (Cfrom 
whatever source)» one can say that the "event has happened". 
This soft event is used by the Micro Scheduler function to locate 
the corresponding process in the wait queue. 
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If the process is in memory Chad not been roiled out)» =the Micro 
Scheduler analyzes the reason that the process had been waiting 
to determine whether or not the Last communicate was completed. 
If it was» the job is put in the ready queue tno await 
reinstatement. If the communicate was not completed» the job is 
put in the communicate queue to wait for the reinitiation of the 
communicate by the communicate handler. 


If the process was not in memory and memory is available» . then 
the "ROLLIN" function is calied. Its duty is to re-establish the 
run structure that had been "rotted out" to disk. The reason for 


waiting is then anatyzed in the same manner described above. If 
there was no memory availabie for rotttine then the job is put 
back in the wait queue to wait for menory. The wait reason will 


be updated to reflect this status change and to specify into 
which gueue the job would have gone had menory been availabte. 
When memory becomes available» the job will be put directly into 
the specified queue. 


The process witl continue to be manipulated in this fashion until 
it has completed execution.» At that time it will request the 
end-of job function from the MCP and terminate. 


6-5 


BLi000 MCP MANUAL 
MARK 10.0 


DEMAND MANAGEMENT 


MCP QUTER LOOP 


The MCP can be viewed as a program whose sote duty is to respond 


to demands made upon it by the systeme This seemingty innocuous 
statement is valid even though the MCP is a vastly complex 
programs. The complexity arises» however» by virtue of the 


diversity of demands to which the MCP is able to respond. 


There are five basic categories of demands to which the MCP 
initially responds. These categories are recognized at the 
outermost or most global Level of the MCP» which iteratively 
searches for eache Once a demand is founds» it is analyzed at 
increasing Levels of detait and resolved according to its 
specific request. Control is then returned to the outer toop 
which continues to search for demands. 


The five types of demands recognized by the MCP*s outer toop = are 
described below. 


TIMER INTERRUPT 


The first type of demand recognized by the MCP is calied a timer 


interrupt. There are two fields in the MCP*s gtiobat data space: 
A software maintained system clock and a clock maske Every tenth 
of a second an interrupt is caused by the hardware. GISMO 


detects this interrupt and bumps the system clocke Every time 
the MCP begins its toop searching for demands» it checks to see 
if the value of the systea clock has exceeded the vatue of the 
clock maskae If it hase the MCP catts the “"NeSECOND"™ routine to 
perform its housekeeping duties and resets the clock mask to some 
value greater than the system clocks, See "NeSECOND routine”. 


£20 INTERRUPTS 


An I/0 interrupt is a soft mechanism by which GI5M0 notifies the 
MCP that an [I/0 operation is complete. GISM0 wilt only do so 
when the MCP requests that it be notified or when an exception 
condition has occurred on the 1/0 operations This should not be 
confused with a "service request™ type of interrupt. This 
service request is a hard level in the processor and is used to 
notify the software that a hardware I/0 control is in need of 
services 
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The NCP wilt request notification of the occurrence of I/0 
completion only when there is a need for it to know. The wsCP 
does not request the return of 1/0 complete interrupts on user: 
I/O operations untess the program which caused the operation to 
be initiated is waiting on the I/0 operation. This is discussed 
further in the sections of the specification. covering READ and 
WRITE 


When an 1/0 operation is conpieteds» GISMOQ stores the result 
descriptor associated with the operation in its proper tocation 
in memory. The field is known as the “result descriptor field" 
and is a part of the actual I/0 descriptor. There is an area 
allocated in memory known as the interrupt stacks which is 
actualdy a queue of 1/0 compiete interrupts. GISMO» after 
storing the resuit descriptor» if the interrupt request bit in 
the descriptor. was one stores the address of the result 
descriptor in the interrupt stack and “causes” the MCP» if it is 
waiting» In its outer toop»s the NCP requests that GISM0O detiver 
the address on the top of the interrupt stack. It analyzes the 
descriptor at that address and takes the appropriate actione The 
MCP continues to request addresses from GISMO in this fashion 
until the stack has been exhausted. 


Upon receiving a descriptor's address from GISMNO» the MCP invokes 
a routine called “I0.COMPLETE” to begin the analysise Depending 
on the vatue found in a field of the resutt descriptor» 
I9 COMPLETE invokes one of the following MCP facilities» each of 
which is discussed in depth» on the following pages. 


CAUSE MECHANISM CSEE “PROCESS MANAGEMENT") 
CONTROL LANGUAGE PROCESSOR 

IDAT MAINTENANCE 

£/0 ERROR HANDLER 

SPO MAINTENANCE 


HOB SCHEDULING AND INITIALIZATION 


After exhausting the interrupt stack» and if an MCP gtobat» 
"CHANGE.BIT">» is true» the MCP checks the “schedule queue” to 
determine if any jobs have been scheduted = for execution. 
CHANGE .BIT wiit be false whenever a previous attempt at program 
initialization failed because of insufficient memory» and nothing 
has intervened to create a possibility of success at this 
attempte The program initialization routine sets CHANGE.BIT to 
zero Cfaise) whenever an initialization fails. It is set to one 
Ctrue) whenever a block of memory is freed by job termination or 
"rotlout"e whenever a new job is placed at the top of the active 
schedudes or whenever explicitly set by the "PS" control tanguage 
statement. The MCP is thus able to maximize its oun resources by 
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bypassing a futile attempt at job initialization. 


The schedule queue contains an active and a waiting schedule. 
Both are Linked dists on disk which contain those jobs awaiting 
execution but for which no memory resources have yet been 
allocated. The control language processor identifies a request 
for a job to be executed. It buidids a tog entry (Csee "LOGGING 

INFORMATION") for that job and links it by priority and time of 


request to other jobs waiting to be initia@tized. See "CONTROL 
LANGUAGE PROCESSOR" for exact specifications» The active 
schedudie Lists those jobs that are ready to rune The waiting 


schedude contains those jobs whose initialization must await the 
occurrence of some event Cis@e» the termination of another job or 
operator control message). When the event happens» the job is 
transferred from the waiting schedule to the active scheduie»s 
where the MCP will find it. 


The MCP selects the first job in the active schedule for 
initialization. once the job has been de-queued» control is 
passed to the “program initializer™ which aidocates the machine 
resources and sets up the structures necessary for the program's 
executions» 


COMMUNICATES 


A program may request certain services from the MCP. These 
requests represent another class of demands to which the MCP must 
responds The “communicate queue" contains jobs which have 
submitted such a request. 


The queuing mechanism is managed as follows. Each run structure 
nuacteus contains two fields? “RS~COMMUNICATE.}MSG.PTR™ which is a 
standard message area and “*RSeQ@eIDENT® which specifies in which 
queues if any» the program ise The value of RS»QesIDENT may be: 


0 = READY QUEUE 
1 = COMMUNICATE QUEUE 
11 = WAIT QUEUE 
“2 = NOT QUEUED Ciee@er running) 
10 = MMCP COMMUNICATE QUEUE 
3 = EXTERMINATE QUEUE 


All run structures are dinked together by priority. Thus the 
menbers of a given queve may be discovered by searching the 
Linked List of run structures and checking RS»Q.-IDENT. 
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The first job in the communicate queue is serviced according to 
the contents of RSeCOMMUNICATEeMSGePTR.e The message is initiatly 
analyzed by the communicate message handling routine which catls 
the proper subroutine to further analyze the message and take the 
appropriate actione The proper subroutine is determined by the 
first two bits of this message area catled “RS~ITYPE*. The 
values and corresponding meanings of this field are as follows: 


00 = INTERPRETER GENERATED COMMUNICATES 

O1 = PROGRAM GENERATED COMMUNICATES 

10 = UNDEFINED 

11 = FILE CLEANUP COMMUNICATE Z 


Interpreter generated communicates contain requests from the 
program*’s interpreter for services which are unrelated to the 
program’s code. These include requests for missing segments» 
trace and run time error messages ete 


Program generated communicates are requests for code related 
services such as iI/0 operations. These are specified under 
"PROGRAM COMMUNICATES". 


The file cleanup conmunicate is an MCP generated communicate used 
in conjunction with program end-of~job. 


PROGRAM REINSTATE 


To be specified. 


PROGRAM COMMUNICATES 


All object programs communicate with the MCP by means of a 
Communicate S~operator. The operator serves toe transfer controt 
from the user*s interpreter to the MCUP"s- Though many 
communicates are now handted by microcode in the Micro“MCP» the 
means of communication has not changed. The compiler generates 
code which establishes an area in the program*s run structuree 
This area generally conforms to a standard format which is 
recognizable by the MCP. The fields in this area are defined 
arbitraritye however. Only the first twelve bits of the field 
must conform to the format presented belou. 
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COMMUNICATE EQRMAT 
VERB OoO- 1.1 
OBJECT 12 - 35 
ADVERB 36 - 47 
CT.1 46 - 71 
CT.2 72 = 95 
CT.4 iz0 ~- 143 
i 244 - 167 
CT.6 168 - 191 
CTa7 192 = 215 
CT.8 216 - 239 
CT.9 240 = 263 
CT.10 264 - 297 
CT.il 298 = 321 
CT.12 322 = 345 
CT.13 346 = 369 
CT.14 370 = 393 
CT.15 394 = 417. 


Note? Alt communicates return a vaiue of 20000000000003 or 
20000180000008 in the RS-~REINSTATE -MSGePTR unless 
otherwise specified. 


| 


All interpreters» when executing the Communicate S~operator» 
store a pointer to the reserved» formatted memory area in the 
field catlLed RS-COMMUNICATE.MSGePTIR of the RS»eNUCLEUS of the 
program being executed.» This forty-eight bit field specifies not 
only the relative address of the communicate area» but also the 
size of the area in bitse For further information on this aspect 
of the operation» refer to the programmatic description of the 
Run Structure Nuctleuse : 


If the MCP needs to convey information back to the object program 
after executing the requested communicate» it does so by setting 
the field cailed RS»REINSTATE.»MSGsPTR to a setected value. If no 
information is to be conveyed» this field is set to either 
2000000000029 or 30000180000002 before reinstating the program. 
Other valuese and their associated meanings depend upon the type 
of communicate being executed» and are described for each 
cosgmunicate in the sections which foiitlow. 
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CT.VERB 00 
ILLEGAL COMMUNICATE 


READ CNICRO NEP) 


CTVERB 01 
CT.OBJECT FILE NUMBER 
CT»ADVERB BIT 


0 REPORT & RETURN TO USER ON EOF 
1 REPORT & RETURN TO USER ON PARITY 
2 REPORT & RETURN TO USER ON INCOMPLETE I/0 
3 LENGTH ADDRESS PAIR 15 PRESENT FOR RESULT MASK FIELD 
4~6 = 
rf STACKERS““STACKER # I5 IN CT.3 
6-11 = 
CT.l LOGICAL RECORD BIT LENGTH 
CTez LOGICAL RECORD BASE RELATIVE BIT ADDRESS 
CT23 RANDOM FILE ACTUAL BINARY DISK KEY 
CRECGCRD NUMBER INSERTED BY MCP FOR SERIAL FILES) 
OR 
LENGTH OF KEY FOR REMOTE FILES 
CTe4 “ADDRESS OF KEY FOR REMOTE FILES ONLY 
CT.5 LENGTH IN BITS OF RESULT MASK 
CT.6 BASE RELATIVE ADDRESS OF RESULT MASK FIELD 
REINSTATEsMSGePTR VALUES : 
Q GOOD READ 
1 END OF FILE 
Z I/O ERROR 
3 INCOMPLETE 170 
4 IMPOSSIBLE SEARCH (RPG SEARCH OP) 


A READ comaunicate on the B1000 System serves to detiver a 
logical record to the user program. It does this by moving the 
record from the I/0 buffer area in memory» where it was 
previously stored by the CSM» to the user's Run Structure 
(Base/Limit) area. In almost alt cases» the READ» WRITE and SEEK 
coamunicates are performed by the Micro-MCP. This has been true 
Since the 5.1 release of the software. 


The information passed in the communicate area must include a 
unique file number. This number is assigned by the compilers and 
is passed to the NCP in CT.OBJECT. The same statement is true 
for att communicates which deal with an {/G operation» such as 
WRITE» SEEKe OPEN> CLOSE» POSITION and so forth. 


The communicate information must also contain the basec-relative 
address of the memory area where the record is to be stored and 
the length» in bits» of this areas These items are passed in 
CT«2 and CyJ«l» respectively. . 
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Logical record size is contained in the FPB»s which is constructed 
by the compiters from information contained in the user's file 
dectaration. In the case of variable-length records» togical 
record size may be contained in the record itself. The length of 
the user's "work area*"» contained in CTIe-l» does not have to be 
equal to the Logical record sizes» If CTel is targer than togical 
records sizes the movement to the work area witt occur 
left-justified with blank fiil on the right. If CT.1 is smatter 
than tlogicakt record siza» truncation from the right wilt occur. 
in the Latter case» information will be tost from the towworder 
postions of the record. 


For a sequential file» the record delivered will be the next 
record in sequence in the file. For a random disk file» the 
record to be moved is specified by the binary number in CT.3. 
Record numbering in a random file on the B1000 system begins with 
ones by definitions regardless of the source language uhich the 
user program is written ine A zero passed in CT.3 witt be 
considered invalid by the MCP and the appropriate action wilt be 
, takens 


If the user program inciuded code to be performed when the end of 
the file ts reached ore in the case of random files» when CT.3 
specifies a number which ts beyond the end of the file or 
describes a record which has not yet been written or is otherwise 
invalid» the specified bit in CT.~ADVERB should te turned on. 


If the user program included code to be performed when an 1/0 
error occurs and cannot be corrected by the MCPs» the proper bit 
in CT.ADVERB should be turned on. If control is returned to the 
user in this case» if the bit in CT.ADVERB is ons the user*s work 
area will contain the record which was read erroneouslye In this 
Case» nothing in the work area should be assumed to be valid. 


Ordinarity» when a user requests a togical record and the 
associated physical I/0. operation is not yet completes the 
program is not attowed to execute untit such time as the 
requested record can be detivered to his work area. For 
sequential files» I/0 operations to fildi all of the 1/0 buffer 
areas assigned to the file are initiated when the file is opened. 
The WCP attempts to stay ahead of the user prograg from that 
points initiating a new I/0 operation to pre ~fitt each buffer as 
soon as it is emptied by the user programe. © 


For some Data Communications applications» it is not feasible for 
the user program to wait until a requested £/0 completes. If » 
for example» the program is reading cards and the card reader is 
not ready» it may be a dong time until the operation completes. 
For such programs» the third bit in CYe-ADVERB is usede- Setting 
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this bit causes the MCP to return control to the user programs 
regardless of whether a record was delivered or not. If no 
record was delivered» the program is informed of the situation by 
setting proper values in RSeREINSTATEsMSGePTR. This is discussed 
in more detail tater in this section. 


Remote files may consist of more than one data communications 
terminal. In such a casee it is necessary for the object program 
to specify the identification of the terminad it wishes to. read 
from. This is accomplished by setting CI.3 and CT.4 to the 
proper values. 


In ait three of the cases described previously» where bits one» 
two or three are set in CY»ADVERS» it is necessary for the MCP to 
inform the user prograw of the existing condition. This is 
accomplished by setting a field in the RS.~NUCLEUS to a specific 
vaiue prior to reinstating the program. The field is defined as 
RE»RETNSTATE»MSGePTR and is accessed by the user*s interpreter as 
soon as it is reinstated» after doing a communicate. If a valid 
record was delivered to the user» the message field is set to a 
value of zero. It will be set to one» two or three if the 
respective bits are on in CT~ADVERB and the condition assigned to 
these bits exists. 


If aouser program READ communicate encounters an endtof~file 
condition and bit one in CT-ADVERB is not set» the program will 
be discontinued by the WMCP. If a user 1/0 operation resutts in 
an irrecoverable error and bit two is not set in the READ 
communicate which requests the records the program witli be 
discontinued by the MNCP. If a user program requests the data 
from an I/0 operation which is not yet complete and bit three of 
the adverb is not set» the program is merely forced to wait for 
the I/0 completion. 


For files which are assigned to Data Recorders and other setected 
card Input/Output devices» the user may specify that the card 
which was read is to be routed to a certain physical stacker on 
the devices» This is accomptished by setting the specified bit in 
CTjADVERB to one and by setting CT.~3 to the binary number which 
designates the physical stacker. In this case» there is never a 
need for more than one buffer area to be assigned to the file» 
and the MCP QPEN routine will prevent this from happening» Card 
I/D operations in this case are not “buffered*™ and card 
throughput will decrease accordingly. 


For randon disk files» a READ communicate may not result in an 
I/G operation being initiated. If the user who does the READ is 
the sole user of the file and if the block which contains the 
requested record is already in memory in one of the user's buffer 


B1i000 MCP NANUAL 
MARK 1020 


areas» the requested record witli be simply moved to his work 
ar@ae This action is not performed if there is more than one 
user of the file. 


WRITE MICRO wep) 


CT»VERB | 02 
CTOBJECT FILE sNUNBER 
CT~ADVERB BIT | 
0 REPORT & RETURN TO USER ON EOF 


=! REPORT & RETURN TO USER ON PARITY 
2 REPORT & RETURN TO USER ON INCOMPLETE I[/0 
3 LENGTH ADDRESS PAIR I5 PRESENT FOR RESULT MASK FIELD 
4=5 = 
6 QUEUE FILES: WRITE TO FRONT OF 
QUEUE ("STACK"). 
7 STACKERS““STACKER # 15 IN CT.3 


8-11 PRINTER SPACING (€4 BIT VALUE) 
NO PAPER ADVANCE 
SKIP TO CHANNEL 
SKIP TO CHANNEL 
SKIP TG CHANNEL 
SKIP TO CHANNEL 
SKIP TO CHANNEL 
SKIP TO CHANNEL 
SKIP TO CHANNEL 
SKIP TO CHANNEL AFTER PRINTING 
SKIP TO CHANNEL AFTER PRINTING 
SKIP TO CHANNEL 10 AFTER PRINTING 
SKIP TO CHANNEL 112 AFTER PRINTING 
SKIP TO CHANNEL 12 AFTER PRINTING 
SKIP T0 TOP OF FORM C150C LPM PRINTER ONLY) 
SINGLE SPACE AFTER PRINTING 
DOUBLE SPACE AFTER PRINTING 
CT.1 LOGICAL RECORD BIT LENGTH 
CT.2 LOGICAL RECORD BASE RELATIVE BIT ADDRESS 
CT.3 RANDOM FILE ACTUAL BINARY DISK KEY 

CRECORD NUMBER INSERTED BY MCP FOR SERIAL FILES) 

OR 

LENGTH OF KEY FOR REMOTE FILES 
CT 4 ADDRESS OF KEY FOR REMOTE FILES ONLY 
CT.5 LENGTH IN BITS OF RESULT MASK 
CT26 BASE RELATIVE ADDRESS OF RESULT MASK FIELD 


AFTER PRINTING 
AFTER PRINTING 
AFTER PRINTING 
AFTER PRINTING 
AFTER PRINTING 
AFTER PRINTING 
AFTER PRINTING 


WON TU WN 


AMO OMDr we GNA Ue whe Oo 


REINSTATE.~MSGePTR VALUES 
0 GOOD WRITE 
i END OF FILE 
2 1/0 ERROR 
3 INCOMPLETE I/0 


A WRITE communicate on the 81000 system operates in a manner 
similar to READ. The user program constructs a togicat record 


t%9 
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somewhere within its Run Structure and communicates with the MCP. 
The MCP wild then move the data from the work area» the address 
and tength of which are described by CT.2 and CTel respectively » 
to the next available I/0 buffer area. The program will be 
allowed to continue as soon as the movement of the data occurs? 
it is not forced to wait for completion of the actuat I/0 
operatione 


As in the case of the READ communicates either blank~fiil or 
truncation of the record will occur» depending upon the sizes of 
the work area and the file*s Logical record. The buffer wilt be 
released» which means that the corresponding 1/0 operation wild 
be initiated» as soon as the buffer area has been filled to 
capacity. A program is forced to wait for I/0 comptietion if the 
MCP cannot find an available buffer to which it can move the 
records A buffer is unavailable if the previous I/0 operations 
which may have been initiated some time ago» is not yet complete. 


End-of-file is not reported to a user on an output file except in 
the cases of disk files and some printer files. End-of~fitle for 
a disk file is defined to be an attempt by the user to write past 
the deciared size of the files. The dectared size of att. disk 
files is maintained in the File Header» a permanent entity 
created when the file is opened output for the first time. 


For fides assigned to printers» end-of-file may be defined to be 
the sensing by the hardware of the physicat end of the pagee In 
all cases» this is not actually the end of the page» but rather 
the sensing of a channel twelve punch in the Carriage Controia 
Tape. This sensing wilt be reported to user programs» if 
requested by setting bit one in CT.~ADVERB and by setting a bit in 
the FPB for the file. Notice that» because of the fact that the 
MCP is examining the result of I/0 operations which may have been 
initiated some time ago» end tof“page is not reported when it 
occurs» but “n"™ write operations taters where “n" is the number 
of buffers assigned to the file. 


1/0 errors are aiso reported to user programs on the WRITE 
communicates if requestede This information is necessarily of 
Little practical user on any Burroughs operating systeme 
Ostensibly» the I/G error routines of the MCPCs) should be of 
such a nature that the need to report this occurrence never 
arises» 


The same Data Communications applications which use bit three of 
the adverb on READ» use it in a similar manner on WRITE. When 
using this bit in the adverbs control is returned to the user 
when a WRITE is requested but the buffer that should be used is 
not yet available to the MCP. Again» this can be caused by the 


7~10 
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device itself going not ready~ 


Printer spacing information must be passed to the MCP on each 
WRITE communicate for ae file which is assigned to a printer. 
This is acconpiished by setting the proper bits in the adverb» as 
pictured in the precedinge 


Serial disk files may be opened by the user program for both 
input and output operations. In other words» the file may be 
opened in such a manner that both a READ and a WRITE communicate 
are acceptable» with no intervening Close and Open. When this 
type of OPEN communicate occurs» the MCP will pre~fill ail of the 
buffers» as if the file had been opened INPUT oniy» but the 
buffers are released at different points in the READ and WRITE 
communicate processing- 


The MCP wiil not move buffer pointers at the conclusion of a READ 
communicates as it normally does. Instead» it must wait until 
the next communicate operator associated with that file is 
received. If the succeeding communicate is a WRITE» it will move 
the data from the work area to the buffer and change the 
operation. code in the I/0 descriptor to a Write. It will mark 
the program “ready to be reinstated"» and then rotate the buffers 
in anticipation of the next communicate operator. In thts 
specifications the term "rotate the buffers* means that the NCP 
moves the necessary buffer pointers and initiates the I/0 if 
necessary. 


If the next communicate received at this point is a WRITE» the 
MCP» after insuring that the next buffer is available for use» 
wii move the data again» from the work area to the buffer and 
rotate the buffer pointers. If the communicate had been a READ» 
the MCP would have moved the data in the opposite direction and 
it would not have rotated the buffer pointers. 


In summarye for this type of file» two successive READ operations 
widl move two successive records from the file to the user's work 
are@ae Two successive WRITE operations wiil cause two successive 
records to be written into the file. A sequence of operations 
such as READ“WRITE“READ“WRITE wilt cause two successive records 
to be delivered to the user and the same records» but not 
necessarily the same data» to be written in the file. The 
End-of-File pointer for a sequential file may tbe extended when 
the file is opened in this manner. 


Disk files which contain variable~fiength records may not be 
opened for both input and output oper ations» or for random access 
processinge 
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For Sequential I/0 files» .a# physical I/0 operation is not 
necessarily initiated each time the user program does a WRITE. 
For blocked files» if the user has done a WRITE on any record in 
the block» the operation widl be initiated only when the buffer 
pointers are moved past the end of the block. 


For data communications files» the fieids described as CT.3 and 
CT.-4 are used on WRITE communicates exactly as they are on READ 
communicates. 


For random disk files a WRITE communicate may result in more than 
one physical I/0 operations If the fite is biocked» the btock 
which contains the requested record must be in a buffer in memory 
before the record is inserted in the block and actuaily written 
to disk. This is due to the fact that the hardware can oniy 
initiate I/0 operations and terminate them on segment boundaries. 


If the block which contains the requested record is not in memory 
when the WRITE is issued» the MCP wild initiate a Read operation» 
force the requesting user to wait for its completions move the 
record into its respective position in the biock after the I/0 
completes» attlow the user to be reinstated at this point and 
initiate the requested Write operation» if the file is being 
aceessed in the RANDOM acde. 


In the 6.1 retease of the software» a file access method known as 
DELAYED RANDOM was implemented. When DELAYED RANDOM is used» the 
first request for a logical record of a given block of a DELAYED 
RANDOM file will result in a physical 1/0 which reads the 
necessary block into memorye Subsequent accesses to the block 
widl not generate any physical 1/0%s as long as the biock remains 
in memorye A block is overlayed if a request is made for a block 
not currently in memory» at this time the Least recently accessed 
block is chosen as the one to overlay. If the chosen block has 
been updated in memory it is written to disk before the new block 
is read. Periodicatly» all blocks that have been updated in 
memory are written to disk by the SNCP. 


SEEK CMICRO MEP? 


CT.VERB 03 
CT»UBJECT FILE»NUMBER 
CT-ADVERS = 


CT»l = 
CT.2 - 
CT»3 RANDOM FILE ACTUAL BINARY DISK KEY 


T-1i2 
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The SEEK communicate is an instruction to the MCP to position the 
arms property» on movable~warm devices» and to fili one of the 
buffers assigned to the fite with the bleck of data which 
contains the requested togicai record. This communicate is 
applicable to random disk files oniy. The user is not forced to 
wait for the completion cof an I/O operation initiated by a SEEK 
communicate. He may be forced to wait if there is no buffer 
available to use for the operation. 


The SEEK communicate may be used by the user programmer to mask 
some or ail of the time required by a READ communicate with 
computation. It may also be used» prior to a WRITE communicates» 
to eliminate the necessity of waiting for a buffer to be 
pre filled when using blocked filese . 


No data is moved to or from the user*s work area by the Logic of 
a SEEK communicate. 


20RTER CONTROL 


CTVERB 04 
CT.QBJECT FILE.NUMNBER 
CT»~ADVERB BIT 


0-4 = 

5 TRANSFER 

6 POCKET SELECT 

rs STOP“FLOW 

8 BATCH-COUNT 

9 POCKET LIGHT 

10 me 

il ENDORSE 
CTo1 POCKET NUMBER 
CT.2 BASE RELATIVE TRANSFER ADDRESS 
CT.3 BIT LENGTH OF TRANSFERRED DATA 


The SORTER CONTROL communicate is used in conjunction with files 
assigned to Reader“Sorters onlye Such files may be utilized 
propertly in COBOL programs only. Other languages way include 
portions of the syntax necessary’ for proper use of a 
Reader~Sorters though onty COBOL contains everything that is 
necessarye 


When the MCP receives an I/0 Complete interrupt from the 
Reader-Sorter» it immediately references the program which is 
using that sorter» determines the memory address of the “USE 
ROUTINE work area™s and piaces a formatted copy of the result 
descriptor from the I/0 operation followed by an image of the 
item itself in the work area. It then reinstates the user at the 
code address of his USE ROUTINE. (For additional inforsation on 
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Item Processing» refer to the B1000 COBOL Reference Manual» Forno 
Number 1057197.) 


The MCP takes the action described above regardiess of other 
processing that is occurring. The action described is commonly 
known as "HighPriority Interrupt Handling”. 


Oniy three of the five possible adverb bits may be set in a 
communicate addressed to the NCP while the user program is 
executing the USE ROUTINE. These three bits are TRANSFER» 
STOP“FLOW and POCKET SELECT. The TRANSFER bit is discussed in a 
subsequent paragraph. Tf the POCKET SELECT bit is set» the MCP 
widdi use the value in CT.»1l as the pocket number on the sorter for 
that item. If the STOP“FLOW bit is set in the adverbs the MCP 
will also issue the appropriate I/0 Descriptor to the sorter. 
After receiving the communicate» regardiess of the adverb bits» 
the MCP will continue doing whatever it was doing at the time the 
interrupt was received; the user must give up control at this 
point. 


Pocket selection on the sorter thus happens asynchronously with 
everything that is occurring on the systems except the sorter. 
This is currentiy the onty device connected to the B1000 which 
operates in such a manners The necessity for this. action is 
dictated by the fact that the sorter is actuaily a *“real-tinae” 
device and must be serviced in a specific time period after a 
check has been read by the hardware. 


The TRANSFER bit and its function was added to the 8.0 version of 
the MCP. When the TRANSFER bit is not set» which will be the 
case for ait programs compiled prior to the 8.0 release of the 
softwares the MCP» upon receiving the POCKET SELECT communicates 
will dispatch the pocket number supplied to the sorter control 
and place an image of the item in a “tank™ area in memory. The 
number of items. that may be contained in the tank area is 
specified by the user and corresponds to the number of buffers 
requested for the sorter file. In actuality» there will be only 
one buffer and 1/0 descriptors regardless of the number 
requested» but the buffers requested witl be used to determine 
the size of the tank area. 


Item images will be removed from the tank when the user program 
does a SORTER READ operation on the sorter file. The images will 


be delivered in sequence to the programe Obviously» the tank 
area will become full if items are introduced to the system more 
rapidly than the user program does SORTER READ operations. If 


this occurs» the MCP will dispatch a STOP“FLOW 1/0 descriptor to 
the sorter controls thus stopping the tatroduction of items. 
Flow wilt be automatically started by the MCP when the tank area 
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is again empty. In this manner» the system prevents 
TOO_LATE_TO_POCKET_ SELECT and TOO_LATE_TO_READ conditions from 
occurringe . 


If the TRANSFER bit is set in the SORTER CONTROL communicate» the 
MCP wid not tank the actual image of the item but wilt store the 
data at the tocation specified by CYIe2 and CTe3 from the 
program's run structure. In this manner» the user may cause the 
MCP to tank whatever he chooses» thus eliminating the need (for 
several programming steps from the user program. A maximus of 
one hundred characters may be passed and tanked per item. 


The BATCH“COUNT bit in the adverb is used to advance the batch 
counter on the sorter by ones each time it is received by the 
MCP. This adverb bit wild only be accepted by the MCP when the 
user program is not in the POCKET SELECT USE ROUTINE» and a High 
Priority Interrupt condition does not exist» 


Each pocket on a Reader Sorter has a red indicator tanap»e visible 
to the operators above it. The dights may be turned on 
programatically by the object program issuing a SORTER CONTROL 
communicate with the POCKET LIGHT bit in the adverb sete Upon 
receiving such a communicates the NCP will issue an I/0 
descriptor to the sorter which will instruct it it turn on the 
light above the pocket specified by CT»i. The hardware will onty 
take such action when the flow of items through the sorter has 
been stopped. The same is true of the BATCH COUNT operation. 


SORTER READ CMECRO MEP) 


CT»VERB 05 

CT-GBJECT FILEeNUMBER 

CTw~ADVERB = 

CT.1 READ AREA BIT LENGTH 

CTe2 READ AREA BASE RELATIVE BIT ADDRESS 


Check Citen) images are passed to the user prograan 
asynchronously. As described above» an item image is passed to 
the program whenever one is available to the system. The user 
program is expecting to READ these images synchronously» however» 
by issuing SORTER READ communicates. 


The MCP therefore temporarity stores these isages in memory» 
passing them to the user program in successions upon receiving 
this coamunicate. (CNotice that the user prograaz has already seen 
the images in his POCKET SELECT USE ROUTINE.) This operation is 
commonly known as "tanking". | 


veils 
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The operation of the SORTER READ communicate is simitar to that 
of READ. Item images are passed to the user*s work area by the 
MCP> the length and location of the work areas is specified by 
CT»1 and CT¥e.2 respectively. 


There is actually a secondary purpose to the SORTER READ 
communicate? it informs the MCP fo the user program*s processing 
rate As described above» images are passed immediately to the 
user for pocket selection but any other communicate from within a 
POCKET SELECT USE ROUTINE is prohibited. The images may not be 
written to disk or saved by the user in any manner»> except when 
they are received via a SORTER READ communicate. 


Therefore» if the soft “tanks"™ of item images maintained by the 
MCP begin to fit. up» which indicates that the sorter is 
delivering images faster than the user can process them» the MCP 
wid automatically stop fiow on the sorter untid the user program 
catches Upe The sorter may therefore operate sporadicaltys» in 
bursts» but ail items will at deast be pocket selected. 


The image of the item in the tank is preceded ty a twenty~four 
digit Cninetycsix bit? expansion of the actual resuit descriptor 
received from the hardware in connection with that item. This is 
passed to the user program on the SORTER READ communicates» just 
as it is placed in his USE ROUTINE work area prior to reinstating 
his USE ROUTINE. 


Though onty two communicate formats are inaplemented for use with 
Reader~Sorters»s the MCP must do a tot more to make this operation 
possible. A program which opens a sorter causes many different 
items to be marked nonwoverlayable in menory. This is described 
aore fully under the OPEN communicates For a more comprehensive 
explanation of Reader-Sorter operatione refer to the B1000 COBOL 
Reference Manual» Form Number 1057197 


OPEN COM2 
CT»VERB 06 


CT-OBJECT INVOKE NUMBER & PATH NUMBER 
CTeADVERB BIT 


0 INCLUDES PACKID OF DICTEONARY 
1 ame 
2 DMeSTATUS FORMAT 

O=BINARY 


1=4-BIT DECIMAL 

ON EXCEPTION 

UPDATE 

REORGANIZATION € REORG ONLY) 
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CT»i DMeSTATUS REGISTER BIT LENGTH 
CTa2 DM-STATUS REGISTER BASE RELATIVE BIT ADDRESS 
CT.3 DATA BASE NAME BASE RELATIVE BIT ADDRESS 
CT a4 DATA BASE NAME BIT LENGTH 
CT.5 PACKID BASE RELATIVE BIT ADDRESS (BIT O OF 
CT»ADVERB = 1) 
CT.6 PACKID BIT LENGTH CBIT 0 OF CT.ADVERB = 1) 
CLOSE (OM) 
CT.VERB 07 
CT»OBJECT = 
CT.ADVERB BIT 
O-1 ™ 
2 DMeSTATUS FORMAT 
O=BINARY 
1=4-B8IT DECIMAL 
3 ON EXCEPTION 
4-11 - 
CT.1 DMe STATUS REGISTER BIT LENGTH 
CTo2 DM~STATUS REGISTER BASE RELATIVE BIT ADDRESS 
OPEN 
CT»~VERB 08 
CT-OQBJECT FILEsNUMBER 
CT.ADVERB BIT 
0 INPUT 
i OUTPUT 
2 NEW FILE 
3 PUNCH 
4 PRINT 
5 NO REWIND/INTERPRET (DATA RECORDERS) 
6 REVERSE/POCKET CCARD PUNCH) 
7 LOCK 
8 LOCKOUT 
9 REPORT FILE MISSING 
10 REPORT FILE LOCKED 
ii OVERRIDE NAMING CONVENTION AND SECURITY 


REINSTATEs*NSGePTR VALUES 
0 GOOD GPEN 
1 FILE NOT PRESENT CINPUT DISK) 
PACK NOT PRESENT COUTPUT DESK) 
NO MORE FILES ON MULTI“FILE REEL CTAPE) 
2 FILE LOCKED CDISK FILES ONLY) 


The OPEN communicate serves primarily to associate a physical 


file with the Logical file dectared in the user's program. The 
cosamunicate has other functions and is also used when such an 
association has atready been made. Basicaliy» the processing 


invoked by an OPEN communicate obeys the rules set forth in the 
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definition of the COBOL Language. 


The object program must pass the unique file number assigned to 
the file by the compiter in CT.OBJECT. The MCP will use this 
nugsber to obtain the disk address of the FPB constructed by the 
compiler for that fites It will read the FPB into memory» 
atlocate memory to contain the FIB>s the proper number of I/0 
descriptors and the buffer areas for the file. It wilt then 
construct the FIBs based upon the inforgation in the FPB» the 
physical characteristics of the device assigned to the file and» 
in some cases» the logical characteristics of an existing file. 


The memory area allocated for a file is» except in the case of a 
Data Hanagement file» a contiguous areae One memory tink only is 
necessary to describe a file areas The file area will contain 
ali of the items mentioned in the preceding paragraph. FIBs vary 
in sizes depending on the type of device assigned. No memory is 
allocated for this purpose until a device assignment has been 
madee 


Dae of the first tests made in the OPEN routine is» "Is the file 


already Open?*. This is a violation of the rutes of ald 
languages and the MCP has no choices if the test is true» but to 
discontinue the progran-, There cannot be two consecutive OPEN 


communicates on the same file without an intervening CLOSE 
communicate. 


Another preliminary test is » "Has a device assignment already 
been made?”. If true» the OPEN processing follows a different 
course. Device assignment is of prime importance to the OPEN 
routinee 


Device Assignpent fLExcent Disk? 


A third pretiminary test is whether or not the file is to be 


assigned to disk. If the file is a disk file» the course of 
action followed is described under the heading “Disk File 
Assignment*. The remainder of the discussion under Device 


Assignment applies to nonedisk files» that are being OBpened = for 
the first time. 


The next major test made by the OPEN routine is whether the fide 
is being opened for input» output or both. Only certain card 
devicess such as Data Recorders» may be opened for both input and 
outputs» exchusive of disk files. Certain other combinations of 
the various bits in the adverb are aiso fitegal. These will be 
discussed in turn. For the case mentioned above» atteapting to 
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open acard reader» for examples for output purposes will result 
in the program being DS-ed by the MCP. 


If the file is being opened input» the NCP will attempt to match 
the external names in the FPB of the file» FPB.MNULTI.FILE.ID and 
FPBeFILEeID>s with the tabets read previously by the STATUS 
routine on each peripheral device. If no match is founds the 
operator is notified and the program is forced to wait until a 
file with the requested tabel is introduced to the system» or 
until the operator resolves the "No File* condition is some other 
manners. System SPO and Control Card syntax is availabie to al tow 
the operator this alternative. The program will removed § from 
memory if possibile. 


If a match is found on two or more units» the operator is 
notified of this aiso and againe the program is forced to wait. 
The WCP cannot recover automaticalty from this conditions. the 
operator must inform it that he has resolved the "Duplicate File* 
Situation. Again» systes SP0 and Controt Card syntax is 
available to do this» 


The MCP's Controti Card routine is invoked whenever a card input 
device goes from a Not Ready condition to a Ready condition. The 
routine then reads the first card from the device. If this cards 
or in some cases» a subsequent card causes a job to be scheduted 
for executions the Control Card routine retains control of the 
MCP» reads the next cards and processes it. It wild continue to 
retain controt until the card reader goes not ready» or until a 
DATA card is encountered. If the Controt Card routine terminates 
processing due to the encountering of a DATA card» the physical 
input file described by the DATA card is associated with the last 
job which it placed in the schedule. This is onty true if the 
Control Card routine did not tose control between the time it 
encountered the card which caused a job to be scheduled and the 
time it encountered the DATA carde 


The MCP wild not report a Duplicate File situation» if one 
exists» if the input file being opened is a card fite or a 
pseudocreader file and if the job has a physicat file associated 
with it in the manner described above» Rather» the MCP merely 
allows the associated physical file to be opened by the job» 
provided the external identifiers in the physical. tlabel and in 
the FPB are equal. 


Control Card syntax is provided to allow the operator to specify 
the physical unit which contains a specific togical file. This 
specification may be made when the job is scheduled for execution 
or it may be made permanently by modifying the FPB in the 
program*s code file on disk. If such a specification has been 
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mades the MCP*s OPEN routine will not attempt to match external 
identifiers» but witli simply assign the physical file on the 
requested unit to the logical file being opened» provided» of 
course» that the unit is available for such an assignment. It 
shoudd be noted that making such a specification in an FPB also 
changes the hardware type in the FP8 to match the hardware type 
of the unit specified. Units are specified by snemonic name. 


If the unit being opened is a tape units additionat tests are 
necessary before the device may be assigned. The Reet Number 
field in the unit"s lLabed must match the corresponding field in 
the togicat file*s FPB. For tape unitse Multi-File Identifiers» 
Fike Identifiers and Reet Numbers must aii be equal. Aiso»s in 
the case of a tape files» Control Card syntax is provided to allow 
the operator to specify the Serial Number of a particudar reel of 
tape. If this is done» all four conditions must be mete As in 
the case of unit wnemonic speci fications Serial Number 
specification may be made when the job is scheduled for execution 
or it may be made permanently. 


The MCP will allow tape files to be opened when the user 
programmer does not know the logical record and physical block 
sizes actually written on the tape. These fields are teft 
unspecified in the FPB by the compiler but the default bit in the 
FPB» FPB.DEFAULT» is turned one The recording mode of a tape 
fide may also be deft unspecified if the bit is set. The NCP 
will insert the proper values into these fields when the tape is 
opened» provided the information is present in the tape's Labet. 
If the information is not present» the program will be 
discontinued when the OPEN is attempted. 


The wMwMCP will also insert vatues for record and btock sizes uhen 
aif card input files are opened and FPB.DEFAULT is set. 


The MCP wild discentinue any program which attempts to open a 
file contained on seven~track tape if the logical record size 
contained in the FPB for the file is not modulo six and if the 
programmer has specified the tape to be read without hardware 
translation to EBCDIC. This is true regardless of which bit» 
Input or Output» is set in the Adverbe 


When the MCP receives a request to OPEN a file for output 
purposes» one of the first items that must be checked is whether 
or not the file should be assigned to a Backup device» which may 
be tape or disks If the user has requested that the file be 
directed to backup» this will occur before the search for a 
Suitable output unit is made, Backup capabilities are discussed 
in a separate part of this document. 
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Assuming that the file is not to be sent to Backup» the MCP next 
checks to see if the user programmer has requested that the file 
have speciat forms for output. This test is made for att output 
files» regardless of device type. If FPB.FORMS is set to oner 
which indicates that special forms are required» the MCP will 
print an appropriate gessage and force the program to wait until 
the operator replies in the proper manner. Syntax is provided to 
allow thise When the operator reptiess the OPEN routine is again 
invoked and the file will be assigned to the device specified by 
the operator» is anyr provided the unit available. 


In the absence of a Forms specification by the user» the MCP wild 
search the I0AT for an available unit of the type specified by 
FPBeHDWR» As described in a prior sections certain values which 
this field may contain are not actuality hardware types but 
specify a group of types» such as "any tape"» “any head@pertrack 
disk" and so forth. In order to be avaitiabile for output 
purposes» the unit must be ready» must not be currently in use by 
another program and must be write enabled. 


If the MCP cannot find an available unit of the type requested» 
it will check to see if it is permissibte to direct the output to 
a Backup device. If so» it widl attempt to do soe This is aiso 
discussed in the section of this specification describing the 
Backup operation. 


If there is no avaitabie unit of the type specified by the user 
and if it is not permissible to direct the file to a Backup 
device» the MCP wiil print a message on the SPO to inform the 
operator that such a unit is required before the programs which 
will be identified» can proceed. The prograa wilt be forced to 
wait at this points and will be removed from mserorys if possible... 


The NCP may recover the  progran from this condition 


automatically» with no operator intervention» If a suitable unit 
becomes available for output purposes» the OPEN communicate 


processing for the program will be repeated. Controt Card and 
Keyboard syntax is provided to allow the operator to override the 
hardware type specified in the user's FPB. Syntax is atso 
provided to attiow the operator to force the GPEN processing to be 
repeated. In this case» the MCP merely tries again. 


The MCP will automaticaliy discontinue any program which attempts 
to OPEN» for output purposes a fite whose hardware type 
specifies a paper tape reader» a reader~sorters acard readers a 
System SPO or an unknown devices 
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Certain devices on the 81000 may be opened for both input = and 
output operationse These devices are all card devices? no tape 
unit may be opened for both types of operations» except via the 
Enutator Tape constructs. At the present tiges there are only 
three such devices» and they have come to be commonty known as 
"Data Recorders”. Actuallys according to the B1000 Systems 
Index» PeSe 1904 5681» they are the; 


1. B9418-2 80~-Coluan Keypunch@Printer 
2» B9k19"2 96-Cotumn Keypunch=Printer 
3@ B9419—-6 96~-Column Keyonunch-Printer-Sor ter 


All of the devices in the above list have one "Wait Station". A 
Wait Station is used for holding the physical card after it has 
been reads or at deast fed from the input hopper» and before it 
is printed or punched or both. All of the devices Listed have at 
least one hardware buffer» capable of holding the information 
contained on one card. This buffer is used on input operations 
only. “Input” as used here wiil mean input te the computer. 


The table below present the number of input hoppers and output 
stackers on each physical device. 


Device Hoppers Stackers 
CInput) COutput) 
B941B8-2 2 a 2 
B9419-2 2 2 
B94&19—6 2 ) 


Three different I/0 Controls are used to interface the devices to 
the B1000 system-e- They ares 


1. NFC"1 (P.S. 2208 3034) 
2- MFC~2 (PoSe 2208 3034) 
Ze CRPC CPS. 2211 1371) 


The foilowing I/O: operations are defined in the appropriate 
product specification for ait of the controts. 


READ =~ CFrom the buffer in the peripheral). This operation is 
knowns for conversational purposese as the REPEAT-.READ. Valid 
variants are: 

Stacker Select 

Inhibit Feed 

Hopper Select 
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STACKER»SELECT «AND eREAD - CRead the information from the next 
card in the hopper). Valid variants are? 

Stacker Select . 

Inhibit Feed 

Hopper Select 


PUNCH. Valid variants are: 
Stacker Select 
Inhibit Feed 
Hopper Setect 


PRINT. Valid variants are: 
Stacker Select 
Inhibit Feed 
Hopper Select 


PUNCH“PRINT.j Vatid variants are: 
Stacker Setect 
“Unequal Data 
Inhibit Feed 
Hopper Setect 


PUNCH“PRINT~AND.~READ Valid variants ares 
Stacker Select 
Unequal Data 
Hopper Setect 


The ‘Stacker Select variant is actually a three-bit field in the 
I/0 Descriptor. When the three bits are set to numeric values 
other than zero and sevens the device routes the card to the 
stacker selected by the descriptor. Watid numeric vatues for the 
devices range from one to sixe The MCP does not» and cannot» 
edit the numeric vatue passed by the object program to ascertain 
that it is valid for the connected device. 


The Unequat Data variant is valid only in 1/0 descriptors which 
cause a PunchPrint operation to be performed. If the variant is 
not sete the device will print the sage information that is 
punched on the card. In other words» the beginning memory 
address for the information to be printed is the same as the 
beginning memory address for the information to be punched. If 
the variant is set» the information to be printed will be taken 
from a memory tocation which aeedsaresy follows the information 
that is punched. 


The Inhibit Feed variant causes the Wait Station in the device to 
be empty at the completion of the operation. No cards witli be 
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fed from the input hoppers if this variant is set in the 
descriptor. 


The Hopper Select variant causes the feed card to be taken from 
the secondary input hoppers» if there is one. If the Inhibit Feed 
variant is set» the Hopper Select variant is ignored. 


There is a limitations which was mentioned briefiy in aie prior 
paragraph» The MCP cannot distinguish between the B9419-2» which 
has two output stackerss and the B9419-6» which has sixe The MCP 
does not edit stacker numbers before it sends them to the 
controle Therefore» programs which utilize ali six stackers on 
the 689419"6 may not be transported to systems which do not have 
such a device» Even if the MCP could distinguish between the two 
devices» the editing would have to be micro~coded and would 
seriously degrade performance. 


The capabilities availabie to the object programmer are 
programmaticaldy selected by variants on the OPEN communicate and 
by variants on the READ and WRITE coammunicatese The discussion 
is categorized according to the different types of OPEN 
available. 


When the MCP receives an OPEN request with none of the bits in 
the ADVERB area set» it widl assume that the program only wants 
the information contained on the cards and does not intend to do 
stacker selection» Read=Punch operations» or any other variation 
availiable in the hardware. The 1/0 descriptors constructed as a 
resuit of this type of OPEN will all be of the Repeat.Read type. 
There may be any number of buffers associated with the file. Att 
of the buffers will be filled when the file is opened. Stacker 
Selection is not allowed when the fite is opened in this manners 


When the MCP receives an OPEN request with the Pocket bit set» it 
will construct one descriptors» the operator field of which wild 
contain a STACKER. SELECT.AND.~READ instructions The buffer wit 
not be filled when the file is openede The first READ on the 
file will cause the first card in the data deck to be moved past 
the read head and stopped in the Wait Station.» The data from the 
card will be transferred to the object program*s work area before 
control is returned to the program. Stacker Select information 
passed on the first read may or may not be passed on to the 
device and will have no effect at ail. 


The second and allt subsequent reads should have Stacker Selection 
information associated with them. The MCP will not» however » 
include code to insure thise The NCP wild not allow more than 
one buffer to be associated with this type of file. 
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This action is distinctly different from the most common type of 
READ request handled by the NCP. The actual operation is always 
issued after the communicate is receivede and never before» as it 
is with almost ali types of input files. The I/0 operation can 
never be comleted ahead of the demand for it. This operation is» 
however» simitar to the current MCP action for Sequential 1/0 
files on Diske The file can actuatly be thought of as an 
Input/Output files for ali practical purposes. It must be 
considered such a file by the MCP» in order for the I/0 to be 
initiated at the proper time in a card read cycle. The OUTPUT 
bit in the OPEN adverb shouid never be set when the OPEN is 
requested» howevere This wild cause the communicate to have an 
entirely different meaning. 


Quite obviousty» due to the differences in timing» it is 
mandatory that the object program close and re sopen the file in 
order to change from pure INPUT to INPUT WITH STACKERS» and 
conversely. . . 


A number of variations are possible when the device is opened as 
an output files There variations are? 


Ze PRINT 
3=e INTERPRET 
4. POCKET 


The Pocket variant may be applied to any of the first four 
variations» or it may be the only adverb associated with the OPEN 
statemente The MCP» upon receiving an OPEN communicate without 
PUNCH» PRINT or INTERPRET requested» will assume that Punch is 
dasired. Therefore» OPEN OUTPUT is equivalent to OPEN OUTPUT 
WITH PUNCH and OPEN OUTPUT WITH STACKERS is equivalent to OPEN 
GUTPUT WITH PUNCH» STACKERS. 


OPEN OUTPUT WITH PRINT means that the program does not want to 
punch anything into the cards. It onty wants to print 
informatione 


OPEN QUTPUT WITH PUNCH» PRINT means that the program wants to 
punch information into the cards and wants to print different 
information on them. The MCP will allocate the number of buffers 
requested by the programs each buffer widl be 192 bytes long. 
The MCP will expect to receive 192 bytes of information on each 
WRITE communicates 96 of which will be punched in the card and 96 
of which witli be printed. As always» it is not mandatory that 
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the program deliver the full 192 bytes» The move from the work 
area to the buffer is teft-justified with blank fili. 


OPEN GUTPUT WITH INTERPRET ameans that the program wants to punch 
96 bytes of information into the cards and print the same data» 
The MCP wiid aiflocate the number of buffers requested; - which 
must be at least twoe each wilt be 96 bytes in lengthe- The I/0 
descriptor constructed wild specify a PUNCH“PRINT operation» and 
the UNEQUAL DATA bit will be set to zero. The INTERPRET request 
will have precedence over PUNCH» PRINT and a combination of the 
twoe OPEN OUTPUT WITH PUNCH» PRINT» INTERPRET should probably be 
rejected as a syntax error by the compilers. the MCP will accept 
the communicate» however» and assume that the programmer aeant 
only INTERPRET. The same applies to GPEN OUTPUT WITH PUNCH> 
INTERPRET and OPEN OUTPUT WITH PRINT» INTERPRET. 


The POCKET variant may be specified on any valid request for an 
OPEN OUTPUT. The variant is ignored by the MCP on the OPEN 
requeste This is not true for OPEN INPUT WITH STACKERS.j It must 
be true for GPEN OUTPUT» however» to avoid problems which may 
arise when the device assigned to the file is changed by a FILE 
card or an "0U" messagee The WRITE communicate contains a bit 
which requests stacker selection. The NCP examines this bit and 
takes appropriate action on each WRITE comaunicatee 


All of the variations possibile when a file is opened GUTPUT are 
also possible when the file is opened INPUT.~OUTPUT When the mCP 
receives an OPEN INPUT.OUTPUT request with none of the variants 
set» it assumes that the user wants to read the inforasaation from 
the cards» and punch additionai information inte theme and print 
the same information on then. Therefore» OPEN INPUT.OUTPUT is 
equivadent to OPEN INPUT-OUTPUT WITH INTERPRET. . 


The adverbs PUNCH and PRINT are relatively useless when the fiie 
is opened INPUT.~OUTPUT. Both punching and printing occur when 
the PUNCH“PRINT.AND»READ 1/0 operator is dispatched to the 
controid. There is no way the device can be made to print and 
read or punch and read only. These opeations can be simulated» 
of courses» by setting the UNEQUAL.DATA bit in the descriptor and 
loading the proper portion of the buffer with blanks. This. 
requires some action on the part of the programmer. 


The UNEQUAL»DATA bit is set in the I/0 descriptor when the MCP 
receives an OPEN communicate with both the PUNCH and PRINT bits 
set in the adverb. As in the case of OPEN OUTPUT» the INTERPRET 
bit has precedence over both PUNCH and PRINT. OPEN INPUT .OUTPUT 
WITH PUNCHe PRINT» INTERPRET should be considered a syntax error 
by the compiters. When the MCP receives such a requests 
however» it generates a PUNCH“PRINTjAND.READ I/0 descriptor with 
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the UNEQUAL»DATA variant reset. 


Files opened with various attributes require or can only use 
various number of buffers. 


Attributes Requires Can Use 


Input only» not Stackers 1 infinite 
Input only with Stackers 1 1 
Output only. 2 infinite 
Dutput and Input 3 3 


If the nusber of buffers specified for a file is tess than the 
number required» it will be allocated the number required. If 
the number specified is more than the nusber that can be 
effectively used» ait wild be allocated only the number it can 
5 Be 


As in the case of OPEN INPUT WITH STACKERS» the MCP will not fill 
the buffers when the fite is opened. The first READ issued for 
the file will cause a card to be fed» read and stopped in the 
wait statione The information from the card witli be passed to 
the object program at that point. It may be necessary for the 
MCP to treat the first READ on such a file differently from alt 
other reads. This should be of no concern to either the compiter 
or the object programmer. 


After the first READ on the filer the MCP wild normality expect to 
receive two communicates for each card passed through the device. 
There shold be one WRITE request and one READ request for each 
physical card. The program should pass 96 bytes» or 192 bytes» 
of information to the MCP on each WRITE requeste The information 
will be moved from the program's work area to the buffer on the 
WRITE communicates. The actual I/0 operation witli be initiated at 
this time and the program widl be allowed to continue» without 
Waiting for the completion of the operation. 


The MCP wilt normaily expect to receive a READ communicate at 
this points» and the program may be forced to wait for the 
completion of the I/0 operation issued previoust ys After 
completions the inforgation read from the card will be passed on 
the READ coamunicate» as alwayse 


It is not mandatory that the program always foltow the READ/WRITE 
sequence described in the foregoinge If the program issues two 
successive WRITE requests» the input information on one of the 
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cards involved wild be lost to the program. The consequences if 
a program issues two successive READ requests are somewhat more 
dire. The information punched and printed on the first card will 
aiso be punched and printed on the second» © Though this sounds 
rather bad» this could possibly be of some use to someones 


Since the actuat I/0 operation for this type of OPEN is initiated 
om the WRITE communicates», any stacker selection inforwsation must 
be passed aiong with the WRITE communicate, Stacker information 
passed on the READ witd be ignored. | 


The NCP will automaticatly discontinue programs that attempt to 
OPEN a file on any of these devices if? 


1. Neither the Input bit nor the Output bit is on in the 
Adverbs 


2s Both the Print and the Interpret bits are on in the adverbe 
ore 


3e The program is attempting to use a 96-column device in the 
binary recording mode» 


Disk File OPEN 


When aouser program attempts to OPEN a file which is assigned to 
disk» the first test made in the Open Routine is whether the file 
is a new file which the program is creating for the first time or 
an old file which already exists in the disk directory. In the 
first case» a disk file header will eventuality be constructed in 
memory by the OPEN routine. In the second caser the disk file 
header already exists and is stored in the directory and wilt. 
have to be brought into memory by the Routine. The Open 
procedure for a new fide will be discussed firste 


Programs which attempt to open new files for input and output in 
the serial access mode witli be automaticatly discontinued at this 
pointe Also» programs which attempt to open a new Multi~Pack 
File and have bdanks in the PACK»ID field or the FPB will be 
automatically discontinued. 


! 


If the Open coanmunicate specifies that the file is a code fiie» 

the proper names for the file wilt be stored in the FPB at this 

pointe Alsoe the number of disk areas requested in the FPB will 

be automaticaily set to one. The fact that this is a code file 

will be recorded by the MCP in the FPB for the fite. This . 
information is required uhen the file is closed. 
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If the PACKs.ID field of the FPB contains something other than 
EBCDIC blanks» the program is requesting that the file be 
directed to a user pack with that ID. The MCP wilds at this 
points examine the Pack Information Table maintained in memory 
for a pack with the corresponding identifier - If such a pack is 
present on the system» the routine continues» Otherwiser if the 
user has requested that he be notified when the pack is not 
present by setting the REPORT FILE MISSING bit in the adverb» he 
wid be so notified at this point and controi witl be returned to 
the user through the normal processor queue mechanisms.» 


If the REPORT FILE MISSING bit is not set» a message to the 
operator wili be disptayed and the program will be suspended 
until the requested pack is introduced to the system or the 
operaor overrides the PACKID specified. Control syntax is 
provided to alfiow the operator several means of accomplishing 
thise 


If the file being opened is a muitipack file and if the serial 
nuaber of the physical pack is zero or if the pack is already a 
continuation pack for another sultipack file» the program will be 
automaticaliy discontinued. If the number of areas requested for 
the file by the programmer is greater than 105» it will be 
automatically set to 105 by the MCP. In the tatter case» no 
warning is sent to the operator. 


Memory for the file header is allocated at this point. If the 
user had requested that the disk areas to be assigned to the file 
be attocated when the file is opened» the ailecation is done at 
this points provided sufficient disk is avaiiable.e If sufficient 
disk is not available» the program is suspended and an 
appropriate message is displayed on the SPO. 


The Fite Header is now constructed in memory» based upon 
information contained in the FPB. #$=The uitimate dispensation of 
the header is dependent upon the type of CLOSE communicate 
performed on the file. 


At this point in the OPEN processings the logic becomes the same 
for new and old files. Before proceeding with a description of 
the logic at this point» it will be advantageous to describe the 
processing which occurs when the user opens an existing file. 


When the user requests an Open of an existing file> the first 
occurrence is a determination of whether or not the file is 
present on the systeae All three names in the FPB must match an 
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existing file if the name fields contain something other than 
EBCDIC blankse 


If the PACK»ID Fieid is bianks the tite is assumed to reside on 
system disk.» The directory on the system disk will be searched» 
If the PACK»ID field is not blanks» it specifies that the fite 
exists on a removable user pack of that name. I€ there is no 
such pack on the system at that time» the programa is suspended» 
with an appropriate operator messages until the pack is 
introduced to the system or the operator overrides the PACK.~ID in 
the FPB. There are several means provided for the operator to 
accomplish this. If the REPORT.FILE.MISSING bit is set in the 
communicate adverbs the program is not suspended» but control is 
returned to it through the normal processor queues and the fact 
that the pack is not present is reported to ite In either cases 
the OPEN cannot proceed past this point. 


After the decision above» the MCP next searches the directory on 
system disk or on a user pack for a file identified by the names 
in FPB.MFID and FPB.»~ID. {If the fide is not founds the action is 
identical to that described abovee If the file is found» further 
decisions are necessary. 


If the LOCK bit is set in the OPEN adverbs» there may be no other 
users who are writing to the file. There may be other users of 
the filer but none of them may be using the fitie for output. If 
the LOCKOUT bit is set in the OPEN adverbe there may be no other 
users of the files the user who is presently opening the file 
must be the sole usere If these conditions are not meter an 
operator message is displayed and» depending upon the setting of 
the REPGRT FILE CLOCKED bit in the adverbs» the user is either 
suspending or notified of the condition. 


Assuming that ali of the conditions specified are net 
satisfactorily» the File Header is brought into memory by the 
MCP» aif it is not there already» and the user count field in the 
header is incrementede If the OUTPUT bit in the adverb is set» 
the output user count field is aiso incremented. 


At this point in the OPEN processing» alt of the paths converge. 
If the file is not a disk file» a device has been assigned to it. 
If the file is a disk file» the Fite Header is in memory and its 
associated disk areas» if any» are essentiaily “assigned™ to the 
file. The File Information Block C(FIB) aust now be construct ed. 


Construction of the FIB is a rather mechanical process» After 
initializing certain fields in the [/0 Assignment Table CIOAT)» 
memory to contain the FIB is ailocated» if this has not atready 
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occurred. As mentioned in a prior sections the amount of memory 
allocated for an FIB is dependent upon the type of device 
assigned. 


The FIB itself is constructed from information contained in the 
FPB»s from information in the Disk File Header»e and from the 
parameters passed in the OPEN communicate. After this occurs,» 
the I/O descriptors are constructed. Memory space which contains 
the I/70 descriptors and their associated buffers is allocated 
with the FIBs such that the FIB contains not oniy the fite 
information but aiso the descriptors and buffer areas» The 
menory necessary is then a contiguous biock. This statement does 
not apply to Data Management System buffers» which are allocated 
separatelye 


For serial» input only files» each 1/0 descriptor is initiated as 
it is constructed. The buffers are hence “prefilled” by the 
operating system when the file is opened. This is true of alt 
files except those assigned to a reader-sorter and those assigned 
to a data recorder where the user has specified that stacker 
selection is to be performed on the cards.» 


For output files which are not assigned to disk» tabels are 
constructed and written according to the user's specifications. 
Tape tabets. are discussed in the portion of this document which 
describes Magnetic Tape Management» For input files» the device 
assigned will be positioned such that the first READ issued by 
the program yeilds the first physicat record from the device. 
This is often accoaptlished by the Open routine. 


If the user has requested that translation be performed by the 
software» memory to contain the Translation Tabie specified by 
the user is atidocated by the Gpen routine» The Transtation Tabte 
is adso brought into memory by the Open routine and pointers. to 
it are constructed in the FIB. If the specified Transiation 
Table is not present on disk at the time of the Open» the program 
is suspended and an appropriate operator message is displayed. 


If the LOG System Option is set» entries are made in the log when 
the file is opened. The FPB for the file is also the iog entry 
and certain fields therin are updated and modified. At the 
conclusion of the Open processing» control is returned to the 


user if OPEN was invoked by a communicates. In ati Languages 
except COBOL» OGPEN aay be invoked by ai READ» WRITE or SEEK 
communicates. If this was the case» controd is returned to the 


appropriate communicate handier via the systems processor queues. 
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CLOSE 
CT.VERB 09 
CT.OBJECT FILE »NUMNBER 
CT»~ADVERB BIT 
0 REEL 
1 RELEASE 
2 PURGE 
4 3 REMOVE 
4 CRUNCH 
> NO REWIND . 
6 OVERRIDE NAME CONVENTION AND SECURITY 
7 LOCK 
8 IF NOT CLOSED 
9 ROLLOUT 
10 AUDIT SWITCH 
il 


TERMINATE 


The CLOSE communicate allows the user to specify the dispensation 
of files that he has created. Shouid a program terminate without 
performing a Ciose on any fite that he has opened» the MCP will 
assume that the device assigned to the file is to be returned to 
the system*s resources and that the data contained in the file 
should not be retained. 


A second purpose of the Close routine is to bring the I/0 
activity on a device» which happens somewhat asynchronously with 
a program*s processings to an orderly halt» It also returns any 
memory assigned to the file to the system. Cleariys an 1/0 
descriptor and buffer area cannot be returned to avaitabie memory 
until the [70 operation it describes is complete. In order to 
accomplish this» it is often necessary for the Close routine to 
give up control of the processor and regain it when certain I/0 
operations go to completion. 


The first test performed by the Close routine is whether or not 
the file has ever been opened. A CLOSE coegmunicate issued = for 
such a file is considered a programming error and the program 
wild be discontinued at this point. This is done primarily to 
inform the object programmer of the fact that there is something 
is wrong. ’ 


The second test performed by the Clase routine is whether or not 
the file is open now. It is considered a programming error if a 
user requests a Close on a file that is atready closed» as 
opposed to never having been openeds if the IF NOT CLOSED bit is 
not set in the CLOSE comaunicate adverbe The program will be 
automatically discontinued if this error is detected. If the IF 
NOT CLOSED bit is set in the adverb and the file is already 
closed» controt is returned to the user program through the 
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normal processor queue mechanisme Ail other bits in the adverb 
will have no effect and the file is not closed @ second time- 


Before proceeding with a description of the mechanics of the 
CLOSE communicates it will be beneficial to explain the function 
of the various bits in the adverb.j The REEL bit is used on files 
which are assigned to magnetic tape only» It is ignored by the 
code if the file is assigned to any other device. It causes the 
MCP to ciose the reet of magnetic tape that is currently being 
processed. The file will be closed and the reel witt be Locked 
by the MCP. If the user program issues another OPEN communicate 
for the file» the next reei of the file» in numerical sequence» 
will be sought by the Open routine. 


It is not necessary for the user program to issue CLOSE REEL 
cosgmunicates when the physicai end of the reet is encounter ede 
This is done automatically by the HCP. Reel-to~reel transition 
is accosaplished without the involvement of the user programs. 


The RELEASE bit in the adverb means that the resources assigned 
to the file are to be returned to the system. New disk fides 
which are closed with RELEASE will have their assigned disk 
areas» if anys returned to the list of available disk. Permanent 
disk files which are closed with RELEASE will have their user 
count fields decremented but will remain in the disk directory. 
Devices other than disk will be marked available for use by other 
jobss provided their physical status permits. 


The PURGE function is applicable to files assigned to disk or 


tape only. It is ignored if the file is assigned to other 
devicese If a CLOSE PURGE is performed on a “file which is 
assigned to a tape unit» the tape reet will be rewound and 
purged» provided it is write enabled. If it is not 


write~enabled» CLOSE PURGE will be equivaitent to CLOSE RELEASE. 
For a permanent disk file which is closed with PURGE» the file is 
removed from the directory» provided the user who is doing the 
CLOSE is the sole user of the file» and the disk space assigned 
to the file witl be returned to the availiable tabie. A new disk 
files» often known as a “temporary” files will not yet be entered 
in the disk directory» but the disk space assigned to it wilt be 
returned to the available table alsoe In the case of a temporary 
file» there can be only one user and it is not necessary to check 
user counts before purging. 


The LOCK bit in the adverb is intended to be used on files which 
are assigned to disk and tape only. It is ignored if the file is 


assigned to other devices» When a file assigned to tape is 
closed with LOCK» the tape reet is rewound and the unit*®s status 
is marked as "Locked" in the IGAT. The unit wilt not be 
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available for use by other jobs until the operator intervenes» 
either by making the unit not ready and then making it ready or 
by entering a “Ready” message on the SPO. The intended purpose 
of this function is to prevent the MCP from assigning the unit to 
other jobs before the operator has had a chance to remove any 
tape files which may have been created on the unit. 


The LOCK bit» when set on a CLOSE directed to a file which is 
assigned to disk» causes the file to be entered in the disk 
directory if §t is a temporary file> subject to the restrictions 
below. If the file is a permanent file which is already in the 
directory» the LOCK function is equivatent to the RELEASE 
function. 


A file may not have its name entered in the disk directory if 
there is already a file by that name in the directory. A user 
who attempts:.to CLOSE LOCK a file» the name of which is already 
in the directory causes what is known as a “Duplicate Library” 
condition. The program will be suspended at this point and an 
operator message describing the conflict will be displayed. The 
operator must intervene at this point and cause the existing fide 
to be removed» or instruct the MCP to change the CLOSE LOCK 
coamunicate to a CLOSE PURGE or CLOSE RELEASE. Syntax is 
provided to atlow thise 


The REMOVE bit in the adverb is intended to be used on disk files 
ondys Its function is to aliow temporary disk files to be Closed 
with LOCK without operator intervention. It operates in a manner 
similar to CLOSE LOCK except that if a Duplicate Library 
condition arises» the existing file is removed from the directory 
and the disk space assigned to it is returned to the available 
tabie automaticaliy. The function is performed by the MCP with 
no operator intervention required. The new disk file is then 
entered into the directory and control is raturned to the users 


The CRUNCH bit in the adverb was originally intended for use by 
the compilers. This restriction is not enforced» however» and it 
may be used by any program whose source tanguage includes the 
construct necessary to set the bit in the Communicate formate 
Its purpose is to return any disk that was requested but not used 
by the file to the available disk tablee The unused disk must 
lie beyond the End-of-File pointer for the file and the file may 
have no rore than one disk area assigned to it. When a Close 
with CRUNCH operation is performed on ae fite» always in 
conjunction with the LOCK bit» the number of segments per area in 
the file header is modified by the Close routine such that it is 
exactly equal to the amount of disk used. The header is then 
written to disk» per the LOCK bit» and the unused space is 
returned to the system. 
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The NO REWIND bit when set is applicable to magnetic tape files 
only. It causes the sagnetic tape to be positioned immediatety 
beyond the last tabet record written. The unit remains assigned 
to the program and is not available for use by anyone else. The 
user then has the option of opening another file in the forward 
direction» thus creating or continuing a multi-file tape» or of 
opening the file just written as input in the reverse direction. 


The IF NOT CLOSED bit atlows a user to close a file that is 
already closed-s Ordinarity» this is a programming error and wild 
resuit in the user*®s being terminated by the MCPs» as described in 
a prior paragraph. This bit is merely a means. of avoiding 
termination. 


File Information Blocks» I/0 descriptors and buffer areas require 
substantial amounts of memory. The ROLLOUT bit in a CLOSE 
Coamunicate was provided to allow a user to temporarily close a 
files leaving the associated device assigned to the program» and 
have. the FIB stored on disk so that it does not waste memory 
spacee When the file is reopened» it is merety a matter of 
reading the FIB in from disks updating certain fields therine and 
proceeding. This is often quicker than recreating the entire FIB 
and it elimiates the possibility of another program gaining 
control of the peripheral device in the interina. 


The TERMINATE bit in the CLOSE adverb is set when the MCP*s 
termination routines cail the Close routine. This occurs onty 
when @ program terminates» normality or abnormailyr and the 
peripheral devices are still assigned to the program. 


The MCP insures that the external names associated with a file 
assigned to disk are proper names when the file is closed. When 
a compiler closes the code file it has generateds the external 
nanes of the file are inserted by the Close routine based upon 
information supplied by the user in the Compile Controi Card. 
Also» the MCP will not atlow a disk file to be closed with LOCK 
with a blank multi-file ID. The internal name of the file wilt 
be inserted in FPB.MFID and an operator message will be printed 
when this is attempted. . 


The FPB.LOCK boolean» if set» wilt cause the LOCK bit in the 
CLOSE adverb to be turned on when the file is closed» provided 


the TERMINATE bit is atso set. This causes the file to be 
entered in the disk directory and was added as an aid to 
debugginge Oecasionaliys» when a program has a fatai errors disk 


files that the program was using at the time are helpful to the 
ebject programmer in determining what caused the error. Locking 
the file in the directory enables the programmer to Look at the 
data he was processing when the error occurred. 
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The CRUNCH bit in the adverb will be turned on automatically by 
the MCP if the file being closed is a backup file» a pseudo-deck 
or a code files The LOCK bit will be turned on if the file is a 
backup file or a code file and if it should be entered in the 
directorye This tatter case can onty be determined from 
information contained on the Compite card which is not readily 
available to the compider. 


Any file which was opened with the output bit set in the OPEN 
adverb» any file to which the user may have been itssuing WRITE 
communicatass requires some special attention by the MCP during 
the Close procedure. Since physical I/0 operations happen 
asynchronously with the user programe output I/0 operations may 
have been initiated or marked ready for initiation and be 
incomplete or not even in process at the time the MCP receives 
the CLOSE communicates The actuat Close operation must therefore 
wait for the comptetion of ail output I/0 operations associated 
with the file that is being closed. 


Input files present some similar probleas. Since ail of the 
user*s buffers are filled when the file is opened» provided the 
file is accessed serially» and since the MCP attempts to stay 
ahead of the user progras in initiating 1/0 operations» as soon 
as the user has read ald of the records from a buffer» physical 
I/0 operations may be in process or marked ready for initiation 
when the file is closed» In the case of an input file» it is not 
necessary for the MCP to wait for £/G coapletion. <Any operations 
which have not been physicality initiated may be cancelled by 
removing them from the channel chaine The MCP must wait for the 
comptietion of any I[/0 operations that are already physicality in 
process» but this is a relatively short time period. 


In the case of Sequential I/0 and Delayed Random disk files» the 
data in the buffer may have been aitered by a Write operation 
from the user but the I/0 descriptor may not yet have been marked 
ready for initiation. The Close routine will insure that att 
such buffers are actuat@ly written to disk prior to the coaptletion 
of the Ciose operation. Similarly» for serial» blocked output 
fikess the user may have done several write operations but not 
yet fitded an entire buffer. The [7/0 descriptor in this case 
aiso. wiit not yet be marked ready for initiation but the buffer 
widl contain data which must be written to the physical aedia. 
The Close routine witli initiate ail such operations and insure 
that they are completed satisfactorily before atlowing the fite 
to be closed. 


In order for the events described in the preceding paragraph to 
occurs the physical media must remain accessible. In other 
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words» if the unit goes not ready and there are I/0 operations 
which must be compteted before a Chose can occurs the program 
wilt remain in a waiting condition until the unit goes back to a 
ready condition and the necessary operations are complete. 
Keyboard syntax is provideds however» to attlow the operator to 
override this restriction. The syntax shoudd be used only when 
the user program is being aborted.se — The output data in the 
buffers wiil be lost if the syntax is invoked and the data in the 
file wilt be suspect. Further» if the device is a magnetic tape» 
the MCP wiil not be able to write closing tape marks and tabels 
on the media and an 1/0 error will result when the tape is read. 
Possiblys no I/0 error witt results» which may be worsee 


The Chose routine next begins operations which are dependent upon 
the type of device assigned. In the case of a card reader which 
is closed by a user» the device may contain cards which have not 
yet been read by the program. The MCP will cause the cards to be 
passed through the reader» stopping when the device goes not 
ready or when the next control card is encountered. 


In the case of areadersorter» code segments would have been 
marked nonwovertlayable in memory when the file was opened. These 
code segments will be marked overiayable by the Close routine» 
provided the user who issued the CLOSE is the sole user of a 
sorter. Reader~sorter files may only be closed when the flow of 
documents is stopped. Also» they may only be Closed with 
Releas ee The MCP will interpret all Close operations on sorter 
files to be Close with Release» regardiess of the setting of the 
RELEASE bit in the adverbs 


By fare the most complicated processing occurs when the file is 
assigned to disk.» If the file is a multipack file» the Base Pack 
must be online at the time of the Close. The Close procedure 
will not proceed past this point if it is not. 


The MCP next attempts to do the LOCK’ function described 
previously.» New disk fites will be antered in the disk 
directory» provided there is no file with gan identical name 
already in the directory. 


Existing files tn the disk directory cannot be removed under any 
circumstances if they are in use» Simitariy» files ctassified as 
“System” files cannot be removed» even though their user~count 
field in the disk header is zero. The MCP code file being used 
is an example of such a file. Existing files wiil be removed by 
the Close routine if the REMOVE bit is set in the CLOSE adverb or 
the RNOV system option is set» if the Close routine encounters a 
duplicate file in its processing. if neither of the above 
conditions are true» the program wilt be suspended at this point 
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and the operator must intervene to resolve the conflict. 


If the file is a permanent file and if the user has added records 
to the file white it was open» the end~of~file pointer in the 
file header witi be adjusted by the Close routine. 


If the PURGE bit is set in the adverb and the file is a permanent 
file or if the file was temporary and is being Closed with 
Release» the disk space used by the file is returned to the 
available table. 


If the file being closed is assigned to tape» the Close routine 
writes tape marks and labels on the tape. Also» the Close 
routine sends a rewind descriptor to the unit» if not prohibited 
by the type of Close being per formed. 


The inforsaation in the [Q0AT is updated by the Close routine. 
Test and Wait for Ready I/0 descriptors are rectinitiated» if 
appropriate. Ail of the user's 1/0 descriptors are removed fron 
the I/70 chain. 


Information in the FPB is updated and stored on disk in the 
working copy of the FPSB. Finaliy» the memory assigned to the 
file is returned to the system*s available menmorye Controt is 
returned to the user through the normai processor queue 
mechanisms e 


POSITION {MICRO HCP (BACKUP ELLES ONLY?) 
CTVERB 10 


CT.OBJECT FILE »NUMBER 
CT»ADVERB BIT 


0 REPORT & RETURN TO USER ON EOF 

1 REPORT & RETURN TO USER ON PARITY 

2 REPORT & RETURN TO USER ON INCOMPLETE 1/0 
3-7 

8 POSITION TO END OF FILE 

9 CTei CONTAINS PRINTER CHANNEL NUMBER 


10 CTo-1 CONTAINS RECORD COUNT AS A FIXED NUMBER 
ii CT.1 CONTAINS RECORD NUMBER DESIRED 
CTo1 DEFINED BY BITS IN CTADVERB 
REINSTATEs»MSGePTR VALUES 
' GOOD POSITION 
END OF FILE (OR END OF PAGE ON PRINTER) 
1/0 ERRGR 
INCOMPLETE 1/0 
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The POSITION communicate allows the user to change the physical 
and logical position on a file. It is used with serial files 
only» of coursee The file may be assigned to disk» tape or to a 
printers The communicate is ignored if the file is assigned to 
any other device. 


Positioning a printer file wilt be discussed first. If the 
POSITION communicate is directed to a printer file» CTo1 witt 
contain either a channet number which witl correspond to a punch 
in a carriage control taper or a number which will specify the 
number of lines the printer should be spaced.» If bit 10 in 
CT»ADVERB is one CT.1 will be assumed to contain the channet 
nuaber » If the bit is off» CT.1 witl be assumed to contain the 
number of linese 


The Position routine will always space the printer the number of 
lines requested. Due to the design of the 5Bi000 Printer 
Controls» it spaces the printer two lines per descriptor and» if 
the number of lines requested was an odd nuraber» issues a space 
operator for one Line to complete the operation. if a channet 
twelve punch in the carriage control tape is reported anytime 
during the spacings End-of-page is reported to the progras when 
the operation is complete. It is therefore possibler though 
highly inefficient» to cause several pages of paper to be passed 
through the printer with one POSITION communicate. Endo f-page 
is always reported to the user» if it was reported to the MCP» 
regardless of whether of not he has included code to handle the 
situations Programs are not automatically discontinued if there 
is no such code. 


If CT.1 contains a channel number» and if the channel number is 
less than twelves the routine constructs and sends an I/0 
descriptor to cause the printer to space to the requested 
channei. If the channei nuaber if CT~1 is twelve or greaters a 
message is printed on the SPO and the communicate is ignored. 


With some restrictions» disk files may be positioned forward or 
backward a specific number of records or they may be positioned 
to a specific record number within the file or they may be 
positioned to the end of the file. The file may be opened = for 
input or for output but it may not be opened for both. 


Randow disk files and files with variable Length records may not 
be positioned at ali.» Attempting to do so wiilt resuit in the MCP 
automatically discontinuing the progr ame 


Input disk files may be positioned to the end of the file» but 
may not be positioned beyond. Attempting to do so wiil result in 
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the file being positioned to the end of the file. Output disk 
files may be positioned beyond the end=of-file pointer but may 
not be positioned beyond the dectared physical bounds of the 
fide. The “declared physical bounds” of a file are the number of 
records per area declared times the number of areas in the file 
declaration. . 


Files may not be positioned to a negative record number. 
Attempting to do so will result in the file being positioned to 
the first record in the file automaticaity. 


In alt cases mentioned above» the first bit in the adverb must be 
s@te Attegpting to position a disk file to or beyond the 
end-of-file pointer or to the first record in the file or a prior. 
record wittl result in the MCP automatically discontinuing the 
program if the Report and Return EGF bit is not sete This is 
applicable regardiess of whether the file is opened for input or 
output purposese 


Fiies assigned to tape may aiso be positioned forward and 
backwards provided the file does not contain variable=Length 
records. Attempting to position such a file wild result in the 
program being discontinued by the MCP. Also» tape files witt be 
positioned to the first record in a file or to the 
end tof -the~file» provided the first bit in the adverb is setr in 
the same manner as disk files. 


In order to function property» the MCP maintains a record count 
for adi tape files ona “per reel” basis. When the Position 
routine receives the communicates it first computes the record 
number desired by the programe | If the record count desired 
exceeds the current record counte the tape is positioned in the 
forward direction to the desired record. 


The record count for any reel of tape is set to zero when the 
file is opened. This is applicable regardless of the type of 
Close previousiy performed on the fite» if there was a prior 
Closes. Hence» when a tape reet is opened in the reverse 
direction» Record One is actuaity the Last physical record on the 
tape. The “forward” direction is therefore defined to be the 
direction that the tape is currently being passed. When a file 
is opened reverse» a “Backspace” operation will cause it to move 
toward the physical end of the reeit. 


Tape files may not be positioned to the end of the file if the 
file is opened output or if it is opened reverse or if it is not 
an ANSIIw-dlabeied tape. When a Position to end-of-fite occurss 
the record count field maintained by the MCP wilt be Lost» since 
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the I/0 operator addressed to the unit wilt be a "Space to Tape 
Mark. The record count field aust therefore be recovered from 
the ending tabet and ANSTI tabels are the onty labels which 
guarantee that a record count field is present. 


The B1000 tape subsystem is capable of spacing tape one physical 
record per I/70 operation or to a tape marke. It is not capable of 
spacing for a specified number of physical blocks with one I/0 
descriptors» Hence» spacing to a specific record occurs one block 
at a time. Irrecoverable I/0 errors encountered on any of the 
biocks will result in the program*s being automaticattly 
discontinued by the MCP;if the second bit in the adverb is not 
set». if the second bit is set» the I/D error wild be reported to 
the program and the position communicate wilt be terminated. At 
this points» the record count field maintained by the MCP will not 
be reliable. 


If a tape mark is encountered while the MCP is spacing the tape 
to a specific records End-of-File wilt be reported to the program 
if the first bit in the adverb is set. The program wilt be 
automaticadiy discontinued if it is note 


ACCESS FILE PARAMETER BLOCK CEPR) 
CT.VERB 11 


CT-OBJECT FILEsNUMBER 
CT»ADVERB BIT 


o-io0 = 
11 O=READ 
1=WRITE 
CT.1 RECEIVING FIELD BIT LENGTH 
CT.2 RECEIVING FIELD BASE RELATIVE BIT ADDRESS 


The ACCESS.FPB Communicate allows the user access to any of his 
Fide Parameter Biockse The working copy only of the FPB may be 
accessed by this communicate. The FPB is read directly from disk 
into the user*s run structure. The address and size passed in 
the communicate must lie whotty within the run structure. The 
program will be automatically discontinued by the MCP if this 
rule is violated 


Information is not formatted by the MCP. If the FPB definition 
in the MCP is changed for any release of the software» it is the 
user*s responsibility to make corresponding changes in his 
programe 


The communicate operation is ignored if CT.aQOBJECT specifies a 
file which is nonexistent or if the user attempts to read Less 
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than 56 bits of an FPB. 


Changes made to the FPB while the file is open wild not be 
effective until the file is opened again» Due to the fact that 
the Close procedures use fields in the FPB»e changing a Fite 
Parameter Btock while a file is open may resudt in unpredictable 
errors and even system haltse 


ACCESS FILE INFORMATION BLOCK {FIB) 


CT.VERB i2 
CT.OBJECT FILE.~NUMBER 
CT»~ADVERB BIT 


0-10 = 
11 FORMAT 
O=CHARACTER 
1=BINARY 
CT.1 RECEZTVING FIELD BIT LENGTH 
CT.2 RECEIVING FIELD BASE RELATIVE BIT ADDRESS 


The ACCESS.FIB communicate does not reatiy access the entire FIB. 
It returns only the End~of-File pointer and the type of hardware 
davice assigned to the file. It returns these items in either 
binary or decimal format. The End-of-File pointer is twenty-four 
bits or eight bytes. The hardware type is six bits or two bytes 
respectively. 


Programs will be automatically discontinued if the receiving file 
is not whoily contained within the program*s run structure. An 
ACCESS.-FIB communicate for ae file that is not open witl be 
ignored. 


DATA OVERLAY 


CT.VERB 13 
CT»-OBJECT BASE RELATIVE BIT ADDRESS OF 76 BIT FIELD IN FORMAT 
4 BITS = 


24 BITS BEGINNING ADDRESS 
24 BITS ENDING ADDRESS 
24 BITS RELATIVE DISK ADDRESS 


This communicate is issued by programs which are written in SDL 
and which inctude paged arrays only. The SDL Compiter generates 
code which manages the paged array space and this communicate is 
the means whereby it transfers inforsgation in the paged arrays to 
and from disk. 
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The area described by the fields listed above must tie wholly 
Within the program's run structures Violation of this rule will 
result in the automatic discontinuation of the programe 


The relative disk address passed must lie within the disk overlay 
area altocated to the progran. This has been discussed 
previously under program BOJ facilities. 


Due to hardware Limitations» the overlay area can be no smaiter 


than 56 bits» 


This communicate is not used by COBOL» RPG or. any other progran 
written in a source language other than SDL. 


This communicate uses the program*s overlay descriptor in the Run 
Structure Nucteuse The program is piaced in the WAIT»Q@ until the 
I/G operation initiated by the procedure goes to completion. At 
that time» control is returned to the program through the normad 
processor queuese 


ACCESS DISK FILE HEADER CDEH? 
CT.VERB 44 


CT.-OBJECT BASE RELATIVE ADDRESS OF 30 CHARACTER FILE IDENTIFIER 


PACK»ID CAT MFID CAT FID 
CT»~ADVERSB BIT 


0-5 = 
6 OVERRIDE USERCODE NAMING CONVENTIGN AND SECURITY 
i REPORT SECURITY VIOLATION 
8-9 ~ 
10°11 O=WRITE 
1=READ 


2=READ & FORMAT IN BINARY 
3=READ & FORMAT IN CHARATTERS 
CT.1 RECEIVING FIELD BIT LENGTH 
CT.2 RECEIVING FIELD BASE RELATIVE BIT ADDRESS 
REINSTATENSGePTK VALUES 
0 COMMUNICATE COMPLETE 
i FILE NOT PRESENT OR SECURITY VIOLATION AND 
CT»ADVERB BIT 7=0 
2 SECURITY VIGLATION AND CT-ADVERB BIT 7=1 


This communicate allows the user access to disk file headers 


contained in the system*s disk directory. The receiving or 
sending file described by CT.»~1 and CT.2 must tie within the 
program*s run structure. If it does not» the program will be 


automaticaliy discontinued by the MCP. The field in the run 
structure which specifies the file identifier must be exactly 
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thirty characters in length and must conform to the fixed format 
described in the Communicate tayout above. 


This communicate has four variations as defined by CTeADVERB. If 


CT»ADVERB contains a zero or a one» the sending or receiving 
field is assumed to correspond exactly to the current definition 
of a disk file header. The “current” definition means the 


definition used in the actuadl MCP that is handling the 
communicate operators and not the definition used in any 
subsequent MCP. 


If CT»ADVERB is set to zero» certain fields are moved from the 
program's run structure to the actual disk file header and 
written to the disk directory. Oniy selected fields may be 
writtens those not setected are ignored. 


If CT~ADVERB is a one» information is moved directly from the 
file header to the receiving fieitd specified. The move is 
heft-justified with zero fiil. The entire file header aay. be 
read in this manner.» 


If CT.ADVERB is a two or a three» the fields Listed in the table 
below only are moved to the program*s run structuree The 
formatted move aiso occurs teft-justified with no fidling. If 
the receiving field is not sufficientiy flong» the move is merely 
truncated from the right. 


FIELD NAME LENGTH LENGTH 
(BITS) CCHARACTERS) 
OPENS TYPE 24 1 
NO»USERS (Nuaber of Users) 24 2 
RECORD .»SIZE 24 4 
RECORDS»PER»BLOCK 24 & 
EDF «POINTER 24 8 
SEGMENTS »PER.-AREA 24 8 
USERS»OPENjOUTPUT 24 1 
FILE»TYPE 24 2 
PERMANENT 24 | 
BLOCKS ePERe*AREA 24 6 
AREAS-RQST CRequested) 24 3 
AREA»COUNTER 24 3 
SAVE»eF ACTOR 24 3 
CREATION.DATE 24 5 
ACCESS-»DATE (Last) 24 5 
REC.SIZE = 5 
MPF {MuitiwPack Fiite)? 1 1 
PROTECTION 2 1 
PROTECTION.IO 2 1 
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If the file is not present in the disk directory» the program is 
notified by inserting a one in the RS-REINSTATEsMSG.PTR. In 
either case» control is returned to the program through the 
normal -processor queue mechanisme ; 


FINO/MODIFY COM) 


CT»VERB 45 
CT OBJECT INVOKE NUMBER & PATH NUMBER OF THE PATH“NAMNE 
CTe-ADVERB BIT 


0 RETURN LIST HEADS CREORG ONLY) 
i RETURN LOGICAL ADDRESS CREGRG ONLY) 
2 DMeSTATUS FORMAT 

0=BINARY 


1=4-BIT DECIMAL 


3 ON EXCEPTION 
& aa 
5 MODIFY 
6-10 SELECTION EXPRESSION 
O NEXT 
1 PRIOR 
2 FIRST 
3 LAST 
& NEXT AT 
5 CURRENT 
6 AT 
11 DATA SET SELECTION EXPRESSION 
CTel DMeSTATUS REGISTER BIT LENGTH 
CT.2 DMe-STATUS REGISTER BASE RELATIVE BIT ADDRESS 
CT.3 DATASET RECORD WORK AREA BIT LENGTH 
CT24 DATASET RECORD WORK AREA BASE RELATIVE BIT ADDRESS 
CT.5 SEARCH KEY CCAT OF COMPONENT AMES) BASE RELATIVE BIT ADR. 
CT ob INVOKE NUMBER & PATH NUMBER OF DATASET~NANE 


Refer to PeSe 2212 54710. 


afQRE COM) 


CT-OBJECT INVOKE NUMBER & PATH NUMBER 
CSUBSET if INSERT) 
CTe-ADVERB BIT 


0 INSERT 

i = 

2 DMoSTATUS FORMAT 
O=BINARY 


1=4-BIT DECIMAL 

ON EXCEPTION 

BEGIN TRANSACTION CNOT INSERT) 
ENCLUDES.LIST-HEADS CREORG ONLY) - 
END TRANSACTION CNOT INSERT) 


a Ue Ww 


7-45 


B1000 MCP MANUAL 


MARK 10.0 
i NO AUDIT CBEGIN OR END TRANSACTION ONLY) 
8 SYNC CEND TRANSACTION ONLY) 


9 
10 STORE INDEXES ONLY CREORG ONLY) 
11 PSEUDG CREATE CREORG ONLY) 


CT+i DM-STATUS REGISTER BIT LENGTH 

CTe2 DMe STATUS REGISTER BASE RELATIVE FIT ADDRESS 

CT23 DATASET RECORD WORK AREA BIT LENGTH CNOT INSERT) 
INVOKE NUMBER & PATH NUMBER OF DATASET CINSERT) 

CTe4% DATASET RECORD WORK AREA BASE RELATIVE BIT ADDRESS 


CNOT INSERT) 


Refer to P.5. 2212 5470. 


DELETE <0") 


CTeVERB i7 

CT»£GBJIECT INVOKE NUMBER & PATH NUMBER 
CSUBSET IF REMOVE) 

CT»ADVERB BIT 


0 REMOVE 
i - 
2 DMeSTATUS FORMAT 
0=BINARY 
1=4°BIT DECIMAL 
3 ON EXCEPTION 
4-il = 
CT.1 DMe STATUS REGISTER BIT LENGTH 
CTe2 DMeSTATUS REGISTER BASE RELATIVE EIT ADDRESS 
CT=3 DATASET RECORD WORK AREA BIT LENGTH (NOT REMOVE) 
INVOKE NUMBER & PATH NUMBER OF DATASET CREMBVE)D 
CT.4 DATASET RECORD WORK AREA BASE RELATIVE BIT ADDRESS 


CNOT INSERT) 


Refer to PeS». 2212 5470. 


CREATEZRECREATE (DMD 


CT-VERB 18 
CT~0BJECT INVOKE NUMBER & PATH NUMBER 
CT» ADVERB BIT 


¢] = 
Ll RECREATE 
2 DMeSTATUS FORMAT 
O=BINARY 
4=4~-BIT DECIMAL 
3 ON EXCEPTION 
4-11 =- 
CT.l DM»STATUS REGISTER BIT LENGTH 
CT»2 DMe»STATUS REGISTER BASE RELATIVE BIT ADDRESS 
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CT.3 DATASET RECORD WORK AREA BIT LENGTH 
CT.4 DATASET RECORD WORK AREA BASE RELATIVE BIT ADDRESS 
Refer to Ps»S- 2212 5470. 
SHITCH ATAPESDIRECTION 


CT»VERB 19 
CT-OBJECT FILE»NUMBER 
CT».ADVERB BIT 
O-7 NOT USED 
8-11 0 = READ FORWARD 
1 READ REVERSE 
4 WRITE 
REINSTATE»MSGePTR VALUES 
GOOD SWITCH 
FILE NOT OPEN 
WRONG DIRECTION OR NOT A TAPE FILE 
END OF FILE 


il 


ee) 


This operator was added to facilitate the implementation of the 
Tape Sort feature. It has found use in other apptications since 
that times Essentiatly»s it merely changes the direction of a 
tape file without time"consuming Close and Open invocation. 


There is no way that this communicate can cause discontinuation 
of a program. Adi errors are merely reported to the program. 
The file may be changed from input to output» provided it is not 
being read in the reverse direction. Direction may be changed on 
the same communicate which changes the I/0 modee In other words» 
a file may be changed from input and reverse to output = and 
forward with one communicate. 


Buffers are filled by the MCP as a function of this communicate. 
No fields in the FIB are changed» however. Consequently» use of 
this cogsmunicate is not practical on blocked files. 


This communicate will not function if one of the file's buffers 
has atready encountered the physical end of the file. 


TERMINATE CSTOP RUN) 
CT.VERB 20 


This Communicate cails the Terminate Procedure directly. The 
Terminate Procedure is also cadted when a program is being 
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discontinued. There is very Little difference between a normat 
terminate procedurer where the routine is catied via a 


Communicate and an abnormal ones where the procedure is called ay 
the MCP to discontinue a program. 


Programs may not be terminated if they are using a reader~sorter 


and the device is operating. In this case» the terminate 
rountine wilt wait until the flow is stopped on the sorter and 
then proceed with the termination. This is due to the fact that 


HighwPriority Interrupts from the sorter can onty be handled in 
code written exclusively for that purpose. At any rate» all of 
this will be transparent to the user and the program will be 
terminated» though not necessarily at the time the Terminate 
Procedure is first invoked. 


A similar situation exists if the program has Data Management 
operations in process-» 1/0 Complete on such an operation can 
only be handted by Data Management codes and the Terminate 
Procedure witt be forced to wait for coapletion of any such 
operations. 


The Terminate Procedure may also have to wait for Roll-in and 
Roit-Qut operations to be compieted.j The program must be present 
in memory before it can be terminated» 


As mentioned previously» ail of the conditions Listed to this 
point are transparent to the usere The Terminate Procedure has 
its own mechanisms for waiting for such events to be couplete. 
No action is required on the part of the wsere 


The queue of keyboard messages entered via the <Accept response 
will be purged of any messages intended for this program at this 
pointe Refer to the Software Operational Guide explanation of 
the “AX* message for details on this queue. 


At this points» the Terminate Procedure will wait for any code or 


data overlays which may be in process to go to completion. The 
Terminate Procedures if it must wait for such an event» yields 
controi to the outer toop of the MCP. The Procedure witt be 


continued when the I/0 goes to completion. 


Any I/0 operation which was initiated by the program and which 
did not use the normal Fite 1/0 mechanism wilt be hatited and 
delinked from the channet chain at this point. Examples of such 
operations are disk I1/G initiated by the Disk Initiatization 
utilities and aii Data Communications I/0 oper ations.» Temporary 
disk storage obtained by the MCP to execute the program is 
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returned to the disk availabie table. 


The Terminate Procedure next proceeds to ctose all the files 
whitch are associated with the program and which are not yet 
closed.j A file which is closed by a user with no bits set in the 
Close Adverb or with the NO REWIND bit set in the adverb is not 
considered closed by the MCP. The units» in these cases» remains 
assigned to the program» even though there can be no I/0 in 
process for the file. The unit must be returned to the list of 
available resources when the program terminates» Files are 
always Closed with Release by the Terminate Procedures except 
when the file is assigned to disk and FPB.LOCK is set. 


The Terminate Procedure next performs those functions associated 
with memory assigned to the progras. The code segment dictionary 
user count is decremented. If it becomes zero» memory occurpies 
by the code segments and the segment dictionary is returned to 
the available memory ist. Simitlariys» the user count for the 
Interpreter used by the program is decremented. If it becomes 
zeros memory occupied by the interpreter and its segments is aiso 
returned. If the interpreter was partiatly or totally resident 
in M<“Memory» it is removed. This may resuit in a change in the 
mode of MM “Memory management. If so» it is performed at this 
point. 


Similar functions are performed on any Intrinsic Code the program 
may have been using.» The user count for the Intrinsic File and 
for the Code file itself are decremented and stored in the disk 
file header in the disk directory. 


If the Log option is set» the Log is updated at this point. In 
addition to the type of terminations a count of code overlaysr a 
count of data overiays» the current time and date and the amount 
of processor time used by the program are stored in the Loge 


The program*s overlay descriptor is removed from the disk chain» 
a SPG message is printed if the EO0J option is set» and if this 
program was executed by another using the PROGRAM.CALL 
communicates the calling program is marked ready to rune Memory 
occupied by the program's run structure is returned to the 
available pool. The number of jobs running is decremented. A 
bit is set which widl cause the next execution of the OUTER.-LOOP 
to check the active job schedule. 


If any programs are in the Waiting schedule and are waiting for 
the successful termination of this program» they are moved to the 
Active schedules provided this is a normal terminatione If this 
program was a “Compite and Go” or a "Compile and Save"» the code 
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file generated is placed in the active schedule. 


EREE CDM? 


CT»VERB 2i 
CTQBJECT INVOKE NUMBER & PATH NUMBER 
CT~ADVERB BIT 


Oe1:. «= 
2 DMeSTATUS FORMAT 
O=BINARY 
1=4-BIT DECIMAL 
3 ON EXCEPTION 
4711 = 
CT.l DM»STATUS REGISTER BIT LENGTH 
CT.2 DMeSTATUS REGISTER BASE RELATIVE BIT ADDRESS 


Refer to Pw»eSe 2212 54702 


TIMECDATEZOAY 


CTeVERB 22 ; 
CT.GBJECT BASE RELATIVE BIT ADDRESS OF WHERE TO PUT THE RESULT 
CT»ADVERB BIT 
0 1=DATE REQUESTED 
i-2 FORMAT 
0 YY/0DD CJULIAN) 
1 MM/DD/YY 
2 YY¥/MM/DD 
3 DD/MM/YY 
574 REPRESENTATION 
0 BINARY 
4 4-BIT DECIMAL 
2 B~BIT DECIMAL 
3 1=TINE REQUESTED 
6-7 FORMAT 
0 COUNTER 
1 HH3MM2S5.5 C24-HOUR CLOCK) 
2 HH3MM255.25 TT Ci2-HOUR CLOCKs TT=AM/PM) 
8-9 REPRESENTATION 
0 BINARY 
1 4-BIT DECIMAL 
2 O8-BIT DECIMAL 
10 T=TODAYS-NAME REQUESTED 
11 = 
NOTE = TODAYS»NAME RETURNS 9 CHARACTERS LEFT JUSTIFIED 


FORMAT BINARY 4-BIT DECIMAL 8-BIT DECIMAL 
YY/DDD (JULIAN) 74+9=16 84+12=20 16+24=40 
MM/DD/YY 4e5*7=16 B+BtB=24 16+16+16=48 
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yYY7éMM/DD 74#445=16 B+8+*+B=24 16+164#16=48 
DD/MM/SYY 5+4+7=16 Bt84=24 —=164+16416=48 
COUNTER 20 24 48 
HH2MN2S55025 54#64+64+ 4=21 84+84+384+4=28 16+ 16+16+8=56 
HH3MM255.5 TT 446976744416=36 684864644416=44 164+16416484+156-72 
TODAYS NAME : 72 ©€9 CHAR» LEFT JUST.) 


INLILALIZER i120 


CT.VERB 23 
CT-OBJECT BASE RELATIVE ADDRESS OF 
6 BYTE UNIT NNEMONTIC 
OR 
1/0 DESCRIPTOR 
CT-ADVERB VALUE 


0 ASSIGN UNIT TO THIS PROGRAM 

1 RELEASE UNIT 

2 INVALID 

3 LINK IN THE I/0 DESCRIPTOR AND INITIATE 
4 INVALID 


REINSTATE.MSG.PTR VALUES 

IF CTsADVERB=0 THEN 

PORT» CHANNEL AND UNET OF DEVICE REQUESTED 
PORT BIT (3) 
CHANNEL BIT (4) 
FILLER BIT (1) 
UNIT BIT (4) 

ALL OTHER CASES 
© GOOD COMMUNICATE 
1 DISPATCH TO INVALID PORT OR CHANNEL 


This communicate is intended for in-plant use onty.» Anyone 
outside of Santa Barbara Plant who attempts to use this 


communicate does so at his own riske The communicate format and 
function may be changed from time to time. No notice of such 
change wilt be supplied to any user prior to the change. Such 


information will be available on request. 


Released MCP*s will not allow a Write descriptor to be initiated 
on system disks. Attempting to do so will result in the program's 
being DS~-ed. 


The MCP does not assure that the A and B addresses in the I/0 
Descriptor are bounded by the program's Base/Limit registers. It 
is the programmer*s responsibility to do this» Faiture to do so 
wilt result in unidentifiable system halts. 


To use this communicates’ the programmer should first issue it 
with CTeADVERB set to zero and CT.QBJECT pointing to a 
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six"character unit mnemonic. If the requested unit is not 
available for any reason» the calling program wilt be OS~ed. If 
the unit is availabie-, it wiil be assigned to the caiting 


program. It is possible to read any unit without requesting that 
the unit be assigned to yous 


After the unit is assigned to the program» the communicate may be 
issued with CT»ADVERB set to two or threes The MCP copies the 
1/Q Descriptor outside the base~limit before it tinks into the 
chaine When the I[/0 conpletess the IQGeACTUAL~END and I[0.RESULT 
are moved back into the sasewlimit area. When the I/O operation 
js completed» the I/0 descriptor is removed from the associated 
channel chaine In order to again execute the I/0» the program 
must issue another comaunicate with CT.ADVERB set to two or 
threes 


The program shouid issue the communicate with CT-ADVERB set to 
one before it goes to end~of~job. 


It should be emphasized that this communicate was added to the 
NCP for purposes of onwttine pack initialization only and is 
intended for use only by that program» in the form supplied by 
Santa Barbara Plante Requests for maintenance or support fror 
any other source will be ignored. 


WAIT CSNOOZED 


CT»~VERB 24 
CTOBJECT LENGTH GF TIME IN 210THS OF A SECOND 
FUNCTION PROGRAM IS PUT TO SLEEP FOR SPECIFIED LENGTH OF TIME 


zie 


CT~VERB 25 
CT~OBJECT - 
CT»ADVERB a 
CT.1 MESSAGE AREA BIT LENGTH 
CT.2 NESSAGE AREA BASE RELATIVE BIT ADCRESS 
REINSTATESMSGe»PIR VALUES 
0 NG ERRGRS IN ZIP TEXT 
i ZIPPED INVALID CONTROL CARD 


This communicate provides a means for programs to pass control 


cards and keyboard messages to the MCP. There are no 
restrictions on the messages which may be passed. No messages 
are returned to the program by this procedures the only 


information returned is an indication of whether or not the 
syntax of the control instruction was valid. 
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Any program placed in the schedule as a result of a control 
message received from a Zip Communicate wild execute 
asynchronously with and independently of the program which 
executed the ZIP» unless programmatic means for synchronizing the 
two progrags are provided in the programs. 


If the controt instructions passed via the ZIP communicate are 
invalid» a message is printed on the SPO to inform the system 
operator of the occurrences This is necessary» since invatid 
control instructions can result in incorrect oper ational 
behavior. 


ACCEPT 


CT.VERB 26 
CTwOBJECT = 
CT.ADVERB BIT 


0 RETURN IF NO MESSAGE 
imai = 
CT.1 MESSAGE AREA BIT LENGTH 
CT.2 MESSAGE AREA BASE RELATIVE BIT ADORESS 


REINSTATE*MSGePTR VALUES 
0 MESSAGE OF LENGTH ZERO 
aFFFFFF a NO MESSAGE PRESENT 
ANY OTHER VALUE LENGTH OF MESSAGE IN BITS 


This communicate was provided as a means of implementing the 
COBOL ACCEPT verbe- Its use is not restricted to programs written 
in a particular tanguage> it may be used by any programe 


The receiving field must Lie within the bounds of the program's 


run structur@e The program will be forced to wait for an 
operator response if bit one in the adverb is a zero and if there 
is no message in the Accept Queue for the program. Control is 


returned to the program through the normal processor queues when 
aresponse from the operator is received. 


Messages are moved to the receiving field tLeft-justified with 
blank fili. : 


DISPLAY 
CT»VERB 27 
CT.OBJECT - 


CT.ADVERB BIT 
O-i0 = 
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li O=CRUNCH BLANKS OUT OF MESSAGE 
1=PRINT MESSAGE AS 15 
CT»1 MESSAGE AREA BIT LENGTH 
CT.2 MESSAGE AREA BASE RELATIVE BIT ADDRESS 


This communicate was provided as a means of imptiementing the 
COBOL DISPLAY verbs. Like ACCEPT» it may be used by any program. 
It serves merely to print the message described by CTel and CT.2 
on the SPO. 


If bit eleven in the adverb is sets the MCP wild reformat the 
entire message such that non wblank fields in the message are 
separated by no more than one bDbiank. This is merely a 
conventance for the user programmer which may be used when the 
spacing of the words in the message upon the SPO is not 
important. 


USEZRETURN 
CT.»VERB 28 


This comgunicate is not implemented. If received» it is ignored 
and control is returned to the user. 


SORT HANDLER 


CT.VERB 29 
CT.OBJECT BASE RELATIVE ADDRESS OF SORT INFORMATION TABLE 
CT»ADVERB BIT (12) 

2 - SORTeRESTART 

2—- SORT-DUPCHECK 

3 ~- SORT.W1.PID 

4 ~- SORTW2.PID 

5712 FILLER 


CTol BASE RELATIVE BIT ADDRESS OF SORT KEY TABLE 
CT.2 INPUT FILE-NUMBER OR ADDR OF MERGE-INPUT.»TABLE IF MERGE 
CT.3 OUTPUT FILE.~NUMBER 
CTo4 TRANSLATE FILENUMBER OR NOT O 
CT.6 DATA»ADDRESS CDELETE»KEY.»TABLE)D 
CT.7 IF CSORTW1.PID 2= HiaPIDeFLAG) THEN 
DATA» ADDRESS CW1IePID)D ELSE 0 
CT.B IF CSORTAW2.-PID = W2ePIDeFLAG) THEN 


DATAw»ADDRESS C(W2-PID) ELSE 0 


This communicate provides a saeans for the user program to cali 
the Sort Intrinsice For detaits on the implementations refer to 
the proper Sort or Merge Product Specification. 
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SOL IRACE 


CT~VERB 30 
CT~OBJECT TRACE FLAGS 


This communicate is used by ald interpreters which include Trace 
capabilities. Its use is not restricted to SDL only» The 
communicate is merely a means of turning the Trace on and offs 
The print tine is passed via a type 61 interrupt from the 
interpretere The code invoked by this interrupt is little more 
than a cattl on the SDL Read/Write Procedure in the MCP. 


EMULATOR TAPE CMICRO MEPD 


CT.VERB 31 
CT.OBJECT FILE»NUMBER 
CTeADVERB = BIT | 

0-2 OP.CODE 


0 = READ 
1 = WRITE 
2 = SPACE 
3 = REWIND 
4 = TEST 


378 OP.CODE.VARIANT 


3 = REVERSE CREAD» SPACED» ERASE CWRITED» 
TEST »AWATTREADY ~NGT.REWIND CTEST) 
4 = ONEeRETCORD CSPACE)» TAPE MARK CWRITED» 


TESTeWAITNOTAREADY CTEST) 
5 = ODD-PARITY CREADs» SPACE» KRITE)D 
6 = NOISE CREAD» SPACE) 
8 = 


7-8 = NOT USED 
9-11 SCHEDULING. VARIANTS 
9 = FETCHeRESULT 


10 = DONT.WAIT 


11 = REPORT AND RETURN ON IG ERROR 
CTel USER TAPE BUFFER BIT LENGTH 
CT.2 USER TAPE BUFFER BASE RELATIVE ADDRESS 
CT.3 USER ERROR MASK (BIT SET IMPLIES USER WILL HANDLE THE 
CORRESPONDING ERROR) 
BIT 


«MAY NOT USED 

{MAY NOT USE) 

WOT READY 

PARITY CNOT ON TEST) 

ACCESS CNOT ON TEST) 

TRANSMISSION CON TEXT ONLY) 

END2 OF «TAPE 

BEGINNING.OF TAPE 

WRITE~LOCK.OUT 

ENDe»QFeFILE CNGOT ON TEST)» UNITPRESENT CON 
JEST) 


VON OU & Wh mS 
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i0 REWINDING 

11 TIMEOUT CNOT ON TEST) 

12716 (MAY NOT USE) 

17 SHORTe RECORD 

a8 LONG.RECORD 

19 — DROPOUT 

20 INITIATE LATE 

21. CMAY NOT USE) 

22 TRANSMISSTION-~ERROR.MEC 

23 TRANSMISSION»AERRORSNIC 
CT a4 BASE RELATIVE ADDRESS OF USER*S 48 BIT RESULT 


BIT 0-23 OF RESULT CONTAIN THE RESULT DESCRIPTOR 
BIT 24-47 OF RESULT CONTAIN THE ACTUAL LENGTH 
REENSTATE»MSG.PTR VALUES 


0 = RESULT RETURNED 

i = [02ERROR 

2 = RESULT NOT AVAILABLE 
This. communicate was added $0. that the Emutators of 
second=generation hardware produced by Santa Barbara Piant might 
be operated under control of the MCP. It was necessary to add a 


new communicate to do this» since prograas written for these 
machines routinely manipulate magnetic tape in manners which 
violate the rules of the MCP*s togicat i/0 sechanisms. The 
normat file mechanisms in the MCP» which were proauilgated upon 
the specifications of the COBOL tianguages are certainly 
inadequate to atliow all of the many tape operations which were 
common to second generation machinese : 


Essentially» the procedure builds an I/0 descriptor according to 
the specifications passed by the communicate format and initiates 
its. The Emulator program is not allowed to execute until the I/0 
operation goes to comptetion. The procedure is rewentered at 
completion of the operation and the program is then aktlowed to 
continues 


The procedure first tests to see if the file is Open. If it is 
not» the OQpen procedure is called directly from the communicate 
and control is returned to it when the open coapletes. At this 
point» the procedure continues provided the open was successful. 
If it was not» the emulator program would have teen placed in one 
of the processor queues and narked waiting. In the latter casep 
the communicate procedure merely returns controt to the outer 
doop of the MCP. 


The procedure next performs minor editing on the files passed in 
the cormmunicate format. If the operator request involves a data 
transfer», the buffer area described must lie wholly within the 
bounds of the user's run structure. Due to hardware 
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restrictions» certain variants and combinations thereof are 
invalid for certain operation codese The variants here are those 
passed in bits three through seven of the communicate adverb. 
Validity of the variants is checked by the procedure. If the 
user has violated either the bounds check or the variant checks 
the program is automaticaliy discontinued by the MCP. 


The procedure next constructs an I/0 Descriptor which corresponds 
to that requested by the user. The I/0 Descriptor is outside the 
user's run structures A full tape file FIB is allocated» atong 
with space for one I/0 descriptore by the Open Procedure. This 
is done even though many of the fields in it are not used by the 
Emulator Tape Handdier routines directly. Most of the fields are 
required by the Close Procedure. 


The requested I/0 operation is then initiated and the program is 
marked waiting for its completion. Control is returned to the 
outer toop of the MCP at this point and the MCP is free to 
service other userse 


When the I/0 operation compietess the procedure is again invoked. 
It first moves the result descriptor received with the 1/0 
concatenated with a twenty-four bit field which will specify the 
actual length of the operation just completed. The tength of the 
operation is specified in bits. Also» prior to doing the sove of 
the resuit descriptor» the procedure verifies that the receiving 
field is within the run structure of the progr ar. If it is not» 
the program is automaticaily discontinued. 


If the exception bit is set in the result descriptors the 
procedure determines if the exception condition is one that the 
“user has included code to handle himseif. If it is» control is 
returned to the user through the normal processor queue 


aechanism. If the user does not have code to correct the error 
himself» the procedure catis the MCP"s I/70 Error’ procedure 
directly. 1/0 Error wilt then retry a number of times and 


eventualiy return control to the Emulator Tape Handler. If the 
error was irrecoverables the program is discontinued. Otherwise» 
controd is returned to the usere 


COBOL PROGRAM ABNORMAL END 


CT»VERB 32 
This cosmunicate was added so that job streaming may be 
terminated at the discretion of the user. It functions exactly 


as the STOP communicate does except that instead of a standard 
Endrof-Job message» it causes “COBOL ABNORMAL END*™ to be printed 
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on the SPO- <Aiso» any programs that are in the Waiting Schedule 
waiting for this jsob to finish will not be moved to the active 
schedule by the abnormal termination. 


2QRT C04 


CT»VERB » 33 
CTeOBJECT FILE NUMBER 
CT»-ADVERB CLOSE TYPE 


CT.1 END-OF“FILE POINTER 
| CT2 RECORD SIZE 
This cosgmunicate serves to terminates in anorgaltl manners the 


Sort and Merge Intrinsics and to return control to the calling 
program. For details on its operation» refer to the appropriate 
Sort or Merge product specification. 


CREEZEZTHAN RUN SIRUCTURE 


CT.VERB 35 

CTOBJECT BIT 0 CHIGH ORDER BIT) 
O=THAW 
1=FREEZE 


Depending upon the functions being performed by a user programs 
jt may not be permissable for the MCP to change the memory 
location of the program"s run structure or to roll it out to 
disk» The most obvious example of this is the Disk 
Initialization Utilities. which have actual I/G Descriptors 
within their run structure. There are severat other such cases. 


The field in the Run Structure Nucteus» RSe TEMPORARYeFREEZE » 
gives notice to the MCP*s Rotl OGut procedures that this run 
structure may not be soved. This communicate provides a 
programmatic means of bunping and decrementing that field. 


COMPILE CARD INFORMATION 


CTeVERB 36 

4&8 BITS SDL DESCRIPTOR CWHERE TG PUT INFO) IN FORMAT ; 
16 BITS=LENGTH 
24 BETS=ADDRESS 
RETURNS COMPILE CARD INFO [IN FOLLCWING FORMAT ; 
#CHARS INFO 


2, S32 ® @e eevee aeanannsvaenva_seeesaenenenneeseeanennannpensenae 28 8 


30 GBJECT NAME 
02 EXECUTE TYPE 
10 PACKNAME OF THE RUNNING PROGRAM 
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30 INTERPRETER NAME OF THE RUNNENG PROGRAM 
io INTRINSIC NAME CPACK & FAMILY) 
02 PRIORITY 
06 SESSION 
06 JOB NUMBER | 
20 1ST & 2ND NAMES OF RUNNING PROGRAM 
07 CHARGE NUMBER 
01 FILLER 


36 BITS DATE COMPILED 
04 BITS FILLER 


10 USERCODE 

10 PASSWORD 

04 PARENT J0B NUMBER 

20 PARENT QUEUE IDENTIFIER 
ol LOG SPO 

04 SECONDS BEFORE DECAY 
01 PRIVILEGED — 


This communicate returns selected fields from the working copy of 


the Program Parameter Block to the user's run structure. The 
receiving fieid described by the SDL Descriptor must Lie wholly 
within the run structure. The program width be automatically 


discontinued if it does not. The fietds returned are presented 
in the fixed format shown in the table above. 


DYNAMIC MEMORY BASE 


CT~VERB 37 
VALUE IS RETURNED IN COMMUNICATE MESSAGE POINTER AS 
SELF RELATIVE DESCRIPTOR: 


This communicate returns the relative address of the dynamic» or 
overlayables area in the run structures It is intended for use 
by programs written in SOL only. 


MEMORY DUNP IO DESK 


CT.VERB 38 
USED BY ALL LANGUAGES» INCLUDING SDL. 


This communicate causes the program*s run structure and other 
pertinent information to be dumped to disk and tocked in the 
directory with a unique name. The information may be processed» 
formatted and printed dater by a normal state program written for 
that purposes 


Programs which are already in the process of terminating may not 
be dumped. This is academic in this cases however» since a 
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program which was terminating could not issue the communicate. 
Programas which are roiiled out to disk will be roiled back in and 
dumped» via an operator’s action» provided sufficient memory is 
available. Againe if the program were rolled out to disk» it 
could not possibly have issued the communicate. 


The amount of disk which will be required to contain the dump 
file usually exceeds by a considerable margin that required to 
contain just the Base/Liait area of the programs In addition to 
the run structures the duap file will aiso contain the File 
Dictionary» the FIB"s and buffers» the Data Dictionary and alt 
data segments» the code dictionary and the code segments which 
are present in memory at the times and other miscellaneous 
information. If sufficient disk is not available» a message will 
be printed on the SPO and a one wilt be returned to the progran 
in RSeREINSTATENSGePTR. The program will be aliowed to continue 
processing. 


The format of a dump file is as fotltows: 


i. A "Pointer" records» which is described below. 

Ze The program*s run structure and Run Structure Nucteuse 

3s The Data Dictionary. 

4e Every data segment in the dictionarye Segments which are 
‘not in memory will be copied to the dump file from their 
Location on disk. 

Se The File Dictionary. 

be Each FIB and its associated 1/0 Descriptors and buffers~ 
This inctludes ail files that are open and those that are 
closed with no form of releases 

Te The working copy of the Program Parameter B8tock. 

8. The working copy of the initial scratchpad settings. 

9e The working copies of ail File Parameter Blocks. 

10. If the program is written in SDL» the LAYOUT.~TABLE. 

Control is returned to the program through the normal. processor 


queue mechanisme Actually» the program is warked ready to run 
after the scratchpad is copied. 


The format of the “"Pointer™ record is 


7-50 


B1000 MCP MANUAL 


MARK 10.0 
DUMPFILE.»NUMBER BITC24) 
TIME.jOF~DUMP BIT(36) % Julian Date plus Time 
NCP.DATE BITC16) % MCP Version Date 
RELEASE»MCP BITC 4) 
LIMIT-REGISTER BITC24) 
DATA.»DIC.PTR . BIT(24) X Relative Disk Address 
DATA»#SEGS.PTR BITIC{24) % Retative Disk Address 
FEB.~DIC.»PTR BITC24) 2% Retative Disk Address 
FIBePTR BITC24) Z% Retative Disk Address 
PPB.PTR BITC24) kX Relative Disk Address 
NE T»CONTROL»NACRO BITt4) % 1 if Data Cosmunications Handtler 


MC P.»RELEASEsLEVEL BIT(16) 
LAYOUT»TABLE}P IR sTIC24) 
LAYOUT»TABLE. SIZE BITC24) 
DUMP -SYSTEM.ID BITC12) 


GET SES510N NUMBER 


CT»VERB 39 
CTsOBJECT SESSION IS PUT ENTO RS-REINSTATE -¥SG.PIR 


QC eINLTITATE: TO 
CT»VERB 40 
24 BITS PORT 
24 BITS CHANNEL 
24 BITS BASE RELATIVE ADDRESS OF I/0 DESCRIPTOR 


This communicate provides the capability of initiating 1/0 
descriptors on the data communications equipment which may be 
attached to a system. The I/0 descriptor itself if constructed 
by the programs which is usually the Data Communications Handter 
program generated by the NDL Coapiler. This is not a 
requirements howevers and no test for this condition is made by 
the code in the NCP. The communicate operator may be used by any 
program whose source language contains the proper syntax. 


The program widt be automaticaily discontinued by the MCP if the 
requested [/0 control is not a data communications controt or if 
the control is aiready in use by another program. Also» if the 
address of the I/0 descriptor does not tlie within the program's 
run structure or if the program attempts to initiate an 1/0 
descriptor with the “high priority interrupt request" bit set» 
the program will be automatically discontinued. 


After the editing destribed above has been performede the 
requested operation is initiated. Control is returned to the 
user through the normal processor queue mechanisme The program 
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to wait for the comptetion of the operation 


initiateds control is returned immediately after the initiation. 


NOLZMACRO COMNUNICATES 


CY.jVERB 41 
CT~OBJECT INDICATES FUNCTION 
DESC1 BIT 1-48 MESSAGE AREA 1 
DESC? BIT 49-95 MESSAGE AREA 2 
QUEVE.PTR BIT 97-106 REMOTE FILE NUMBER OR STATION NUMBER 
DCWRITE 
CT.OBJECT il 
DESC1 RESULT AREA 
DESC2 DC.WRITE MESSAGE 
NOTES NUMBER AT SUBSTRIDESC2»622) IS MESSAGE TYPE 
&0=FINISH GPEN 
&41=NDL/MACRO PRESENT 
&2=ATTACH STATIONS TO REMOTE FILE 
43=DETACH STATIONS FROM REMOTE FILE 
QUICK QUEUE WRITE SREMOTE EILES2 
CT.OBIECT i2 
DESCL MESSAGE HEADER 
OESC2 MESSAGE 
RMT FL REMOTE FILE TO WHICH THE NESSAGE IS DESTINED 


QUICK QUEUE HRITE STATION NUMBER 


CT.OBJECT 
DESC1 
DESC? 
ST.NR 


13 

MESSAGE HEADER 
MESSAGE 
STATION NUMBER 


ACCESS USERCODE EILE 


CT.»VERB 
DESC 


PARANETER 
NODE 
0 


42 
BIT O~47 DESCRIPTOR TO PARAMETER LIST. 


LIST LAYoOuT 

BIT (4) 

SET ALL PARAMETERS IN LIST EXCEPT USERCODE AND 
PASSHORD.» THESE MUST BE SUPPLIED TQ FIND 
CORRECT ENTRY 

SET ALL PARAMETERS IN LIST EXCEPT INDEX. INDEX 
MUST BE SUPPLIED TO FIND ENTRY. 

SET OVERRIDE} USERCODE AND PASSWORD MUST BE 
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PRESENT TO FIND ENTRY. 

SET OVERRIDE} INDEX MUST BE SUPPLIED TO FIND ENTRY. 

ADD ENTRY» ALL FIELDS HAVE TG BE SUPPLIED. 

DELETE ENTRY» USERCODE AND PASSWORD MUST BE 

SUPPLIED TO FIND ENTRY. 

6 INITIALIZE ALL OVERRIDE BITS. 

/ CHANGE BY USERCODE.] ALL ENTRIES FOR A GIVEN USER™ 
CODE CAN BE CHANGED WITH GNE COMMUNICATE.j USER- 
CODE MUST BE PRESENT» PACK FIELD MUST NOT BE 
EQUAL TO ZERO TO CHANGE IT.j CHARGE NUNBER MUST 
NOT BE EQUAL TO ZERO TO CHANGE IT PRIORITY MUST 
NOT BE EQUAL TO ZERO TO CHANGE IT. 

8 DELETE ALL RECORDS FOR A GIVEN USERCODE. USER~ 
CODE MUST BE PRESENT. |. 

9 SET ALL PARAMETERS IN LIST EXCEPT USERCODE AND 
PASSWORD.» ONLY USERCODE HAS TO BE SUPPLIED 
BECAUSE SEARCH STOPS ON FIRST ENCOUNTER OF 
GIVEN USERCODE. 

10 CHANGE BY INDEX.» INDEX MUST BE PRESENT. 
PRIORITY CAN BE CHANGED BY SETTING FIELD TO NON- 
ZERO. CHARGE CAN BE CHANGED BY SETTING CHARGE 
FIELD TO NON“ZEROs. PASSWORD CAN BE CHANGED BY 
SETTING PASSWORD TO NON-ZERO. 


Wl & W 


11 CLEAR PACK GVERRIDE FEELD FOR ALL OCCURRENCES OF 
THIS USERCGDE.} USERCODE MUST BE SUPPLIED. 
i2 CLEAR PACK OVERRIDE BIT FOR ALL OCCURRENCES OF 


THIS USERCGDE. INDEX MUST BE SUPPLIED. 


INDEX BIT €10) 
USERCGDE CHARACTER €10) 
WHEN SET BY PROGRAN MODE = 0» 22 4» Se 7o Be 9e 11)” 
THE USERCODE MAY OR MAY NOT CONTAIN PARENTHESES. 
IF PARENS ARE NOT FOUND» ONLY THE FIRST EIGHT 
USED. 
WHEN SET BY NCP CMODE = 1) 
USERCODE WILL ALWAYS CONTAIN PARENTHESES. 
PASSWORD CHARACTER (10) 
PACK NAME CHARACTER (€10) 
CHARGE # BIT €24) 
PRIORITY BIT €4) 
PRIVILGD BIT €1) 
OVERRIDE BIT C1) 
REINSTATESMSGePTR VALUES 
O NO ERRORS. 
1 ERROR ON INPUT? EXTHER INDEX IS WRONG OR 
USERCODE/PASSWORD IS NOT PRESENT. 
2 *@CSYSTEMIJUSERCODE" FILE NOT IN "US" SLOT. 


PROGRAM CALLER 
CT»VERB 44 


46 BITS SDL DESCRIPTOR 
24 BIT LENGTH OF TEXT 
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24 BIT BASE RELATIVE ADDRESS OF TEXT 


This communicate functions in a manner similar to the ZIP 
communicate described previously» with one notable exceptione 
The program which issues this communicate is suspended» and 
reaoved from memory» until the program which is initiated by the 
communicate goes to end-of~job.e- This communicates thens provides 
@ means for one program to call another and wait for its 
completions The text which is addressed by the fortyceight bits 
passed with the communicate should be valid MCP Control Card 
syntax which causes the execution of a programe 


Unfortunately» no. means are provided for passing parameters 
between the two programs involved. This can be done only via the 
File mechanism of the MCP. The FILE Control Cards described in 
the Softuare Operational Guide» does provide some assistance in 
this areas 


The text passed by the communicate must lie within the program's 
run structure. The program wilt be automaticaity discontinued if 
it does not.» No further editing is perforaed by the communicate. 
The program which issued the communicate is not informed of the 
validity of the control syntax passede 


LOAD2DUMNP MESSAGE 


CT.VERB 46 
CT~OBJECT BASE RELATIVE ADDRESS OF MESSAGE 
CTeADVERB BIT 

0 1=LOADED O=DUMPED 

1-11 == 


This communicate causes the thirty bytes beginning at the address 
specified by CT-OBJECT concatenated with either the word “LOADED” 
or the word “DUMPED"» depending upon the setting of bit 1 of the 
adverbs to be displayed upon the SPO if and only if the LIB 
system option is set. Refer to the Software Operational Guide 
for details on the LIB option. All nonvwblank ESCDIC fields in 
the message will be shifted to the teft before printing until 
they are separated by no more than one EBCDIC blank. 


COMPLEX WAIT CNICRO NCP? 


CT-VERB 47 
CT-OBJECT NUMBER OF EVENTS 
CT»~ADVERB FIRST EVENT TO CHECK CCHECKED IN CIRCULAR 
FASHION FROM THIS POINT). 
CTelMETC. BIT ENCODED EVENTS CNUMBER SPECIFIED BY CT.OBJECT 
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MAX=15). 
O- 3 EVENT TYPE 
&- 7 EVENT PARAML 
6-15 EVENT PARAN2 
16-24 EVENT PARAN3 
EVENT TYPES: 
O =~ NULL = PARAMI»2>3 = NOT USED 
1 = SPO INPUT PRESENT = PARAM1e223 = NOT USED 
2~ TIME ~ PARAMI»2e3 = CONCATENATED BIT 20 
FIELD CONTAINING THE LENGTH OF TIME TO 
WATT IN 1OTHS OF A SECOND . 
3 - READ OK ~PARAM2: NOT USED» PARAM2: 
FILE NUMBER» PARAM3> NEMBER NUMBER IF FILE I5 
Q=-FILE“FAMILY 
4 ~- WRITE OK - PARAMI»2> 32 SAME AS READ OK 
5S = QUEUE WRITE GCCURRED = PARAM1= NOT USED» 
PARAH2: FILE NUMBER GF OQ-FILE“FAMILY>» 
PARAMS: NOT USED 
6 =~ DATA COMM IG COMPLETE - PARAM1»2»33 NOT USED 
REINSTATE*MSGePTR VALUES . 
ZERO RELATIVE INDEX TO THE COMMUNICATE EVENT LIST ELEMENT 
WHICH IS COMPLETE 


MESSAGE COUNT 


CT»VERB 48 
CT»~OBJECT FILE»NUMBER 
CT-ADVERB 0 DECIMAL FORMAT RESULTS IF TRUE 
COBOL C*PIC 999") 
ELSE BINARY (BIT €24)) 
i-ii - 

CTel RESULT FIELD LENGTH 
CT.2 BASE RELATIVE RESULT FIELD ADDRESS 


FUNCTION RETURN THE COUNT OF THE MESSAGES CONTAINED 
IN THE QUEVETFILE SPECIFIED. IF THE OBJECT 
IS A QUEVE-FILE-FAMILYs THE COUNT WILL BE 
RETURNED AS A LEFT“JUSTIFIED ARRAY OF 
247B81IT COUNTS» ONE FOR EACH MEMBER OF 
THE FAMILY. | 


RECOVERY COMPLETE 
CT.VERB 50 


Refer to PeSe 2212 5470. 
GET-ATIRIBUTIES 


CT~VERB 51 
CT.OBJECT FILE NUMBER 


7~65 


B1000 MCP MANUAL 
MARK 10.0 


CT.ADVERB COMMUNICATE LEVEL (MK 7.0 LEVEL=1) 


CTo1 TOTAL ATTRIBUTES CMUST BE 2 IN 7.0) 

CT.2 BASE RELATIVE ADDRESS OF ATTRIBUTE LIST 
CHANGE SATIRIBUIES 

CT.VERB 52 


CT-OBJEXT FILE NUMBER 
CT ADVERB COMMUNICATE LEVEL (MK 7.0 LEVEL=1) 


CTo1 TOTAL ATTRIBUTES (MUST BE 1 IN 72C) 
CT.2 BASE RELATIVE ADDRESS OF ATTRIBUTE LIST 
ACCESS 2GLOBALS 
CT.~VERB 55 
CTOBJECT 0 =~ CT.3 CONTAINS AN ABSOLUTE MEMORY ADDRESS 


1 = HINTS» CT.3 WILL BE USED AS AN OFFSET 
INTO THE FIELD 
2 ~~ RS-~NUCLEUS.j USE OF CTs#ADVERB AND CTe3 15 
DESCRIBED BELOW 
3 = IOAT.} USE OF CT.ADVERB AND CT.3 IS DES~ 
CRIBED BELOW 
5 ~ PACK.INFO TABLE 
6 = 5P0.59 
CT~ADVERB SEE BELOW 
CTel and CT.-2 A BASEWRELATIVE SDL DESCRIPTOR WHICH SPECIFIES 
THE RECEEVING FIELD IN THE PROGRAM. THE FIRST 
EIGHT BITS OF CT.~1 ARE IGNORED BY THE MCP 
CT.3 SEE BELOW 


Since HINTS actualiy begins at absolute docation zero» there is 
no functionat difference between reading an absolute memory 
iocation and reading HINTS with an offset. Both settings of 
CT.OBJECT are aliowed to accomodate possible future expansion to 
the function of accessing HINTS. 


When reading Run Structure Nuctei» all nuclei are returned iif 
CIreADVERB is set to zero. The number of nuctei that are 
currently present in memory is returned as a seifcrelative value 
in RSseREINSTATEsMSGePTRe All of the nuciei wiit be copied to the 
receiving fietd in the program in the order that they are tinked 
in memory and up to the Limit contained in the size specification 
in CT.d- Uf the nuctei of ail executing programs are transferred 
to the receiving field before it is exhausted» the remaining 
portion of the field will be set to blanks.» 


To access the Run Structure Nucleus of one particular executing 
program» CTeADVERB shoutd be set to one and the job number of the 
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program should be contained as a twenty=four bit binary value in 
CT 23-0 If CT.3 contains zero» the nucleus of the requesting 
program witt be returned. If the nucteus of the program 
specified by CT.3 is not in memory for any reason» the receiving 
fietd widl be set to OFFFFFF2 and filied with blanks and a 
self-relative value of one wiil be returned in 
RSsREINSTATE-MSG.PIR. 


When reading the IGAT»> if CTe-ADVERB is set to zeror CYT.~.3 wilt be 
used as an offset into the IOQAT and the remaining portion of the 
table will be transferred» up to the timit specified in CTsal. 
The vatue of CT»3 may be zero» of courses and the entire table 
may be transferred» If CTeADVERB is set to ones CT¥e3 witt be 
assumed to contain the twenty-four bit binary value of a file 
number associated with a file which the program currently has 
Opens All of the IOQAT entries which follow the associated entry 
may be transferred» depending upon the value contained in CTel. 
If the file ts not open or is not present in memory for any 
reasons a@FFFFFF@ witt be transferred» the remainder of the 
receiving fiedid wiit be set to blanks and RS~REINSTATE.NSGePTR 
will be set to a selferelative value of one. 


If CTe-ADVERB is set to a value of two when reading the IGAT» the 
lowworder twelve bits of CT.3 witli be assumed to contain a 
Port/Channel/Unit combination in the following format? 


Bits 12 ~- 14 Port 
Bits 15 = 18 Channel 
Bits 19 = 23 Unit 


The MCP will scan the IOAT for the entry associated with the 
specified unit and will return that entry plus all subsequent 
entries up to the Limit of the IDAT or that specified in CTel. 
If the specified unit is not present in the IGAT» the MCP witl 
set the receiving field to @FFFFFFa followed by blanks and will 
set RS»REINSTATE»MSG.PTR to a selfrrelative value of one. 


INDEXED SEQUENTIAL POSITION 


CT.VERB 56 
CT»OBJECT FILE NUMBER 
CT-ADVERB BIT 
0 ™ 
1 REPORT TO USER ON PARITY 
2 we 
3 RESULT MASK FIELDS PRESENT 
4-5 = 
6-7 RELATIONAL OPERATOR 
0 EQUAL TO 
iL GREATER THAN 
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2 NOT LES THAN C> 1 =) 
8"10 SELECTION CONDITION 
0 NEXT 
1 PRIOR 
2 FIRST 
3 LAST 
4 NEXT AT 
5 CURRENT 
6 AT 
7 RANDOM 
11 - 
CTel LENGTH OF RESULT MASK 
CT.2 ADDRESS OF RESULT NASK 
CT.3 = 
CT 4 - 
CT.> STRUCTURE NUMBER 
CT .6 KEY ADDRESS 
CT.7 KEY LENGTH 
INDEXED SEQUENTIAL READ 
CT»VERB ey 
CT.OBJECT FILE NUMBER 
CT»ADVERB BIT 
0 REPORT TO USER ON EOF 
1. REPORT TO USER ON PARITY 
2 - 
3 RESULT MASK FIELDS PRESENT 
4-5 = 
67 RELATIONAL OPERATOR: 
0 EQUAL TO 
1 GREATER THAN 
2 NOT LESS THAN (> JI =) 
8-10 SELECTION CONDITION 
0 NEXT 
1 PRIOR. 
2 FIRST 
3 LAST 
4 NEXT AT 
5 CURRENT 
6 AT 
4 RANDOM 
CT.1 LENGTH OF RESULT MASK 
CT=2 ADDRESS OF RESULT MASK 
CT.3 LOGICAL RECORD LENGTH 
CT.4 LOGICAL RECORD ADDRESS 
CT.5 STRUCTURE NUMBER 
CT.6 KEY ADDRESS 
CT of 7 
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UNDEXED SEQUENTIAL WRITE 


CT.VERB 
CT.GBJECT 
CT.ADVERB 


CT.1 
CTe2 
CT~3 
CT.4 
CT.5 
CT.6 


58 
FILE NUMBER 

BIT 

0 REPORT TO USER ON EOF 

i REPORT TO USER ON PARITY 

2 = 

3 RESULT MASK FIELDS PRESENT 
4-11 = 


LENGTH OF RESULT MASK 

ADDRESS OF RESULT MASK 
LOGICAL RECORD LENGTH 

LOGICAL RECORD ADDRESS 
STRUCTURE NUMBER 

KEY ADDRESS 


ZNDEXED SEQUENTIAL REWRITE 


CT.VERB 
CT.OBJECT 
CTADVERB 


CT.1i 
CTw2 
CT.~3 
CT.4 
CTe5 
CT.6b 
CT.f 


29 

FILE NUMBER 

BIT 

0 = 

1 REPORT TQ USER ON PARITY 

2 = 

3 RESULT MASK FIELDS PRESENT 
4-11 -~ 


LENGTH OF RESULT MASK 


ADDRESS OF RESULT MASK 


LOGICAL RECORD LENGTH 
LOGICAL RECORD ADDRESS 
STRUCTURE NUMBER 

KEY ADDRESS 


ENDEXED SEQUENTIAL DELETE 


CTeVERB 
CT.QBJECT 
CT.ADVERB 


CT.1 
CTe2 
CT.3 
CT.4 
CT.5 
CT.6 


6 
F 
B 
0 
1 
2 
3 
4 
L 
A 


> 
K 


0 

ILE NUMBER 

IT 
REPORT TO USER ON PARITY 
RESULT MASK FIELDS PRESENT 


ENGTH OF RESULT MASK 
DDRESS GF RESULT MASK 


TRUCTURE NUMBER 
EY ADDRESS 
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CT.7 ie 


RELATIVE [70 COMMUNICATE = START 


CT~VERB 61 
CT.OBJECT FILE NUMBER 
CT~ADVERB BIT 
0 REPORT TO USER ON EOF 
1 REPORT AND RETURN TO USER ON PARITY 
2 REPORT AND RETURN TO USER CINCOMPLETE 1/0) 
3 RESULT MASK FIELD PRESENT 
4-5 = 
6-7 RELATIONAL OPERATOR 
0 EQUAL TO 
1 GREATER THAN 
2 NOT LESS THAN 
8-11 =~ 
CT.1 LOGICAL RECORD BIT LENGTH 
CT.2 LOGICAL RECORD BASE RELATIVE BIT ADDRESS 
CT.3 ACTUAL BINARY DISK KEY CRELATIVE KEY) 
SUPPLIED BY USER 
CT.4 
CT.5 LENGTH IN BITS OF RESULT MASK FIELD 
CT.6 BASE RELATIVE ADDRESS OF RESULT MASK FIELD 
REINST ATEsMSG.P TR 
0 GOGD READ 
1 END OF FILE 
I7G ERROR 


INCOMPLETE 1/0 
CADDITIONAL TyENS FOR FILE STATUS DEFINED IN THE SEQUENTIAL 
FILES DESIGN SPECIFICATION) 


RELATIVE 170 COMMUNICATE = WRITE 


CT~VERB 62 
CT.OBJECT FILE NUMBER 
CT.ADVERB BIT 


0 REPORT TO USER ON EOF 
1 REPORT AND RETURN TO USER ON PARITY 
2 REPORT AND RETURN TO USER CINCOMPLETE I[/0) 
3 RESULT MASK FIELD PRESENT 
4 ACCESS TYPE 
0 SEQUENTIAL CNEXT) 
1 RANDOM CAT KEY) 


dt & as 
CT.1 LOGICAL RECORD BIT LENGTH © 
CT.2 LOGICAL RECORD BASE RELATIVE SIT ADDRESS 
CT.3 ACTUAL BINARY DISK KEY FOR RANDOM OR DYNAMIC 


FILES (SUPPLIED BY USERs NOTHING IF IN 
SEQUENTIAL MODE) 

CT.4 = 

CT.5 LENGTH IN BITS OF RESULT MASK FIELD 


7-70 


B1000 MCP MANUAL 


MARK 10.0 
CT.6 BASE RELATIVE ADDRESS OF RESULT MASK FIELD 
REINSTATEsMSGePTR 
0 GOOD READ 
1 END OF FILE 
Fe I/0 ERROR 
3 INCOMPLETE 170 


CADDITIONAL ITEMS FOR FILE STATUS DEFINED IN THE SEQUENTIAL 
FILES DESIGN SPECIFICATION) 


RELATIVE [20 COMMUNICATE = REWRITE 


CT~VERB 63 
CT.QBJECT FILE NUMBER 
CT-ADVERB BIT 
0 REPORT TO USER ON EOF 
i REPORT AND RETURN TO USER ON PARITY 
2 REPGRT AND RETURN TO USER CINCOMPLETE I/70) 
3 RESULT MASK FIELD PRESENT 
4 ACCESS TYPE 
O© SEQUENTIAL CNEXT) 
1 RANDOM CAT KEY) 
5-11 = 
CT.1 LOGICAL RECORD BIT LENGTH 
CT.2 LOGICAL RECORD BASE RELATIVE BIT ADDRESS 
CT.3 ACTUAL BINARY DISK KEY FOR RANOGM OR DYNAMIC 


FILES CSUPPLIED BY USERs NOTHING IF IN 
SEQUENTIAL MODE) 


CT 4 
CT.5 LENGTH IN BITS OF RESULT MASK FIELD 
CT 2b BASE RELATIVE ADDRESS OF RESULT MASK FIELD 
REINSTATE*MSG.PTR 
0 GOOD READ 
i END OF FILE 
2 I/0 ERROR 
3 INCOMPLETE 1/70 


CADDITIONAL TTEMS FOR FILE STATUS DEFINED IN THE SEQUENTIAL 
FILES DESIGN SPECIFICATION) 


THE REWRITE COMMUNICATE WILL BE ESSENTIALLY THE SAME AS 
THE WRITE» BUT WILL HAVE A DISTINCT MEANING IN LOGICAL I[/0 


RELATZVE 120 COMMUNICATE = DELETE 


CT~VERB 4 — 
CT»OBJECT FILE NUMBER 
CT .ADVERS BIT 
0 REPORT TO USER ON EOF 
i REPORT AND RETURN TO USER ON PARITY 
2 REPORT AND RETURN TO USER CINCOMPLETE 1/70) 
3 RESULT MASK FIELD PRESENT 
& ACCESS TYPE 


0 SEQUENTIAL CNEXT) 
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2 RANDOM CAT KEY) 


5711 - 
CTeil ue 
CT.2 = 
CT.3 ACTUAL BINARY DISK KEY FOR RANDOM OR DYNAMIC 
FILES CSUPPLIED BY USERS NOTHING IF IN 
SEQUENTIAL MODE) 
CT.4 = 
CT.5 LENGTH IN BITS OF RESULT MASK FIELD 
CT.6 BASE RELATIVE ADDRESS OF RESULT MASK FIELD 
REINSTATE*MSG.PTR 
0 GOOD READ 
i END OF FILE 
2 I/0 ERROR 
3 INCOMPLETE I70 


CADDITIONAL LTEMS FOR FILE STATUS DEFINED IN THE SEQUENTIAL 
FILES DESIGN SPECIFICATION) 


RELATIVE 170 COMMUNICATE = READ 


CT.VERB 65 
CTOBJECT FILE NUMBER 
CT ADVERB BIT 
0 REPORT TO USER ON EOF 
i REPORT AND RETURN TO USER ON PARITY 
2 REPGRT AND RETURN TQ USER CINCOMPLETE 170) 
3 RESULT MASK FIELD PRESENT 
4 ACCESS TYPE 
O SEQUENTIAL CNEXT) 
1 RANDOM CAT KEY) 
oat aad 
CT.l LOGICAL RECORD SIT LENGTH 
CT.2 LOGICAL RECORD BASE RELATIVE BIT ADDRESS 
CT.3 ACTUAL BINARY DISK KEY FOR RANDOM OR DYNAMIC 


FILES CSUPPLIED BY USER* NOTHING IF IN 
SEQUENTIAL MODE) 


CT 4 
CT.5 LENGTH IN BITS OF RESULT MASK FIELD 
CT.6 BASE RELATIVE ADDRESS OF RESULT MASK FIELD 
REINSTATESMSGePTR . 
0 GO00 READ 
1 END OF FILE 
2 I7Q ERROR 
3 ENCOMPLETE I/0 


CADDITIONAL ITEMS FOR FILE STATUS DEFINED IN THE SEQUENTIAL 
FILES DESIGN SPECIFICATION) 


SEQUENTIAL REWRITE CHMEP? 


CT.VERB 66 
CT.OBJECT FILE NUMBER 
CT~ADVERB BIT 


v-T2 


CTeol 
CT.2 
CT.3 
CT.4 
CT.5 
CT 25 
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0 REPORT AND RETURN TO USER ON EOF 
1 REPORT AND RETURN TO USER ON PARITY 
2 REPORT AND RETURN TO USER ON INCOMPLETE I/0 
bE: LENGTH ADDRESS PART [S PRESENT FOR THE RESULT 
MASK 
4711 = 


LOGICAL RECORD BIT LENGTH 
LOGICAL RECORD BASE RELATIVE BIT ADDRESS 
RANDOM FILE ACTUAL BINARY KEY 


LENGTH IN BITS OF RESULT MASK 
BASE RELATIVE ADDRESS OF RESULT MASK FIELD 


INDEXED/SEQUENTTIAL QPEN 


CTaVERB 
CTeOBJECT 
CT»ADVERB 


CT.1 


CT.2 
CT.3 


67 

FILE NUMBER 

BIT 

0 REPORTFILE»MISSING 

1 REPGORT»FILE»LOCKED 

2 REPORT»-EXCEPTION CSECURITY ERRORS) 
3~11 = 


CTHE OPEN TYPE I5 TAKEN FROM THE FPBeADVERB AND 
FPB.w~EXPANDED.»ADVERB FIELDS) 
LENGTH OF USERCODE/PASSWORD FIELD 
CIF GPEN.GN.BEHALF.OF) 
BASE RELATIVE ADDRESS OF USERCODE/PASSWORD FIELD 
OPEN STATUS = RESERVED FOR THE SMCP TO KEEP TRACK 
GF WHERE 170 RESUME IF THE ENTIRE OPEN CANNOT BE 
COMPLETED. 
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JNIER“PROCESS COMMUNICATION 
QUEUE SYSTEM AND INTERFACES 


A message queue system has existed in MCP II since 1973. This 
section describes the current Queue iaplementation and the 
interfaces between the Queue system and other system softwaree 


The word *"Queue™ as used in this document» most often refers to 
the actual data structure maintained by the operating system» 
This data structure is used as a means of interprocess 
communication. Queues may have various attributes just as fiies 
doe For example» Queues may have two ten=character namesr user 
counts» message countse and so forthe fhe data structure is used 
to address a list of messages. This dist may be empty- A Queue 
user may add to the back or remove from the front of this liste 
The Queue may be shared =~ one or more processes may put messages 
in the List and one or more processes may remove messages» Only 
the MCP may access the data structure directly. User programs 
must use other mechanisms» which are constructed from this data 
structures such as Queue Files or Remote Files. 


DESIGN PHILOSOPHY 


The design of the data structure (CFigure 8-1) was strongly 
affected by the need to reduce the S“memory needs of queues. 
Reusable structures like message buffers and message descriptors 
are pooled for the use of the whole queue systen. The memory 
space used by empty message buffers and descriptors is not 
automatically returned to the system. The Queue iaplementations 
rather » retains them for tater use. This results tin quicker 
allocation when this space is required again and in tess 
disturbance of the working set of the code in the system. Since 
Queue Files and Remote Files are unblocked» their FIB*s need not 
have bufferse This minimizes the amount of nemory required to 
contain the FIB. 


QUEUE FILE FAMELZES 


A Queue File Family may consist of a maximum of 1023 Queues» each 
having the same first name or MFID and the same attributes. A 
Queue File Family is shown diagrammatically in Figure 6872. A 
user program may READ a message from one of the individual Queues 
in the fanily or it may request a message from any queue in the 
familye On a WRITE operations however» the individual family 
member must be specified. 
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If individual Queues of a Queue File Family are to be addressed» 
the individual member must be specified by an ordinal number» or 
kaye much Like Switch Files in certain Languages. A key of zero 
specified on a Read of a Queue File Family means that the user 
will accept a message from any of the individual Queues which 
comprise the family. 


QUEUE DESCRIPTORS 


For a given Queues the Queue name»x maximum tengthe pointers to 
first and last messages» etc» are stored in the Queue Descriptor. 
The descriptor must be in memory during the existence of the 
Queues Ysers of the Queue are given "Q~-keys"» which serve as 
pointers to the Queue Descriptor» when the Queue File is opened 
and the user has specified the desired attributes of the Queue. 
For a Queue Files the Q~-key is stored in the file"s FIB.j If the 
Queue is empty» the 360"bit descriptor is the onty memory 
structure dedicated solely to the Queues 


QUEVE Disk 


Messages stored in a queue may reside on disk or in memory. At 
Queue creations an area of system disk is obtained for the Queue 
large enough to hold @eMAXeMESSAGES of size Qe«MAX.MESSAGE.SIZE. 
These two attributes are normally specified by the users A Queue 
specified to contain a maximum of 255 messages» each of a maxinun 
size of 200 bytes wilt require 255 *{{€2004179) DIV 180) or 510 
disk segments» where DIV denotes an Integer Divide operation. 
The required disk space witt be atlocated when the Queue is 
opened» prior to the time it is actually required. This is done 
to minimize the processing required to store the message on disk. 
Users who have minimal amounts of disk storage available may 
controi the amount that is required by Queues by manipulating 
Qe MAX» MESSAGES» The disk space that is allocated to Queues is 
not docked in the directory. If the system fails while Queues 
are actives the disk is returned to the availtabte List during the 
ensuing Clear/Start operation. Disk is always allocated to 
Queues» even if sufficient memory is avaitable to contain the 
maximum nurmber of messagese 


Queue messages are written to disk when a message being put into 
a queue makes the count of messages in memory equal to the 
attribute Q.BUFFERS. When this situation occurs» a disk Write 
operation on the last message in memory in the Queue is 
initiated. This witl make one of the buffers availabie for an 
ensuing insertion in the Queue. There is one exception to this 
Statement. The disk Write operation will not be initiated by the 
Queue routines if the attribute Q.BUFFERS is equai to or greater 
than the attribute Q.MAXeMESSAGES. In this cases messages 
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associated with the Queue may only be written to disk by the 
Memory Management routines» The Memory Management routines may 
write Queue messages to disk anytime memory is required in the 
systems This ensures that Queue messages wilt not fill memory to 
the point where thrashing occurs. 


When a wser removes» or READS» a message from a Queue the first 
message in the Queue is transferred to his Run Structure and the 
naxt message in the Queve is examined to determine if it is on 
disk. If it is» a tookwahead disk Read operation is initiated to 
minimize the time that the user will have to wait for delivery of 
the next Queue message. 


The I/O descriptors that are used for the disk Read and Write 
operations just described reside in the Queue File*ts FIB. For 
each mode of use» input or output» a program opening a Queue File 
is given one I/0 descriptore A file opened input and output is 
given two I/0 descriptors. 1/0 descriptors are shared among alt 
members of a Queue File Famiiy» so that no Queve File FIB will 
ever contain more than two I/G descriptors. 


MESSAGE DESCRIPTORS 


The method of storing messages in the queue is by means of a 
linked list of Message Descriptors. Each Message Descriptor (MmD) 
consists of an 80-bit system descriptor and two Link fields» for 
a total of 128 bits eache The system descriptor actuaily 
describes the message texts according to normal MCP conventionss 


To reduce checkerboarding» MD*s are allocated in blocks of ten. 
Assigning a Message Descriptor to a message is accomplished by 
searching the block(€s) of ten for an available sD. If none are 
available» memory space for an additional block of ten is 
obtained via a cali on the Memroy Management routines. The 
blocks of Message Descriptors are surveyed periodicaltiy to 
consolidate and return unused blocks to the system. At Least one 
block is retained as tong as any Queues exist. 


MESSAGE BUFFERS 


If a queued message is in memoryr the memory area which contains 
the message is known as a Message Buffer (MB). The ML»TYPE field 
in the memory tink which describes the area wilf be set to a 
unique value which denotes a Message Buffer. No Queue will ever 
have more than QeBUFFERS messages in memory at any times 
including those messages which are in transit between memory and 
disk.» Actually» since the Memory Management routines are capable 
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of writing Queue messages to disk and removing them from memory»s 
the Queue routines cannot quarantee that any messages will be in 
memory at any given time. 


QUEVE ATTRIBUTES 


In addition to attributes common to alt files» the user may 
specify two attributes whose interpretation has meaning for Queue 
Files only: 


i. QeMAXsMESSAGES - the maximum number of messages a Queue can 
store» at which point it is considered full Caraximum 1023). 


2s Q@eFAMILY»~SIZE == the number of sub-queues in a Queue File 
Family Cmaximum 1023). 


In addition» Q.BUFFERS as described in the foregoing may be 
specified by the BUFFERS file attribute. Thus» the user may have 
some control over the number of messages that may be contained in 
memory at any given time. In the COBGL Language» a Queue File 
Declaration may appear as: | 


SELECT MY¥-Q@ ASSIGN TO QUEUE. 


FD M¥eQ VALUE OF OQeMAXeMESSAGES IS 20 
RESERVE 3 ALTERNATE AREAS. 
O1 MY.»Q.BUF PIC xC€80Q). 


SELECT MYe2QFF ASSIGN TO QUEUE. 


FD MY-QFF FILE CONTAINS 3 QUEVES 
VALUE OF QeMAXeMESSAGES IS 10 
RESERVE 2 ALTERNATE AREAS. 

O1 MY.QFF.BUF PIC X€80). 


If a Queue File Family is opened» the same attributes apply to 
avery member individually. In MY.QFF above» for example» ati 
three members may hoid ten messages» each having @ maximum of two 
in memory. 


The name assigned to a Queue File is specifed ty the user as the 
MFID/FID combinations For a Queue File Family» the MFID is 
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specified by the user and is taken to be the first ten 
characters» andan FID is synthesized from the member number for 
each queue in the family. The first member of MY.QFF would be 
named “"4Y.QFF/#0000000i1". 


When a Queue File is opened» the MCP compares the 20-character 
name with the names of aii Queues currentiy in existence. If a 
Queue of that name if found» the opener is Linked to the existing 
queue and the Queue's user count is incremented. If the Queue 
does not.exist» anew Queue is created with the attributes 
provided by the FPB. Queue attribute binding occurs when the 
Queue is first created» by the first process te open the AQusue 
File. If two programs share a Queue Ceege» both agree on the 
name)de the first program to open the shared Queue file binds the 
attributes. 


Blocking of records is not allowed in Queue Files. The Record 
Size attribute determines the upper Limit on the tength of a 
message which may be stored in a queue fite. 


QUEUE FILE LOGICAL 179 OPERATIONS 


Queue Fide logical 1/0 operations are rather simpie and 
straight forwards As mentioned previously» alt Queue Files must 
be unblocked. Truncation or blank fill may occurs depending upon 
the size of the user*s work area and the size of the message 
being moved» exactly as is done on ait other togicad I/0 
operations on B1000 systems. The user may request that three 
different exception conditions be reported to him on all Queue 
File togicat I/0 operations. These three conditions are» in 
COBOL syntax: 


1. ON END“OF~FILE 
2» ON EXCEPTION» and 


3a ON INCOMPLETE~IO. 


On READ operations» END“OF“FILE is reported to the user when the 
Queue File is empty and no program exists which has the Queue 
opened for output. EXCEPTION is reported on Queue File Families 
only and on READ operations onty» and actuaity denotes an invalid 
key passed on the READ to specify the desired family member. 
INCOMPLETEcIO is reported if the Queue is empty but programs 
stilt exist which have the Queue opened for output purposes. AlLt 
three conditions are reported only if requested» of course. 
Failure to request that END“OF“FILE or EXCEPTION be reported will 
be considered a program error if either condition occurs and the 
program will be discontinued. 
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The precise meaning of EOF on READ is that Ca) the Last writer on 
this Queue has closed his Queue File and €b) the Queue is empty. 
EOF is treated as a pseudo-message in the Queue. That is» when 
the last message has been read from the @Queue File» the File 
stili exists and actually remains “not empty” for WAIT purposes. 
A subsequent READ will resutt in the EOF branch being taken» “The 
Queue is then emptye but still in ENF statuse so if yet another 
READ is issued on the Queue File» the reader wilt again take the 
EOF branch. EOF can be cleared by either the reader closing and 
reopening the file or by the opening of the Queue by a new 
writere 


READS to specific members of a Queue File Family are treated 
exactly Like READs on single Queue Filese An unspecific READ on 
a Queue File Family with return EOF onty if adl members of the 
Family are at EQF Ciseer empty» no writers). When the tLast 
writer closes any menaber queue of a QFF» the event 
QeWRITE»jOCCURRED widl be caused for the QFF> this witli put a 
reader in the READY.8 when it WAITS on this evente 


A MESSAGE COUNT communicate operator is tmplemented to enable 
user programs to determine if any messages are present in the 
Queue Files they are using» This function is described in a 
Later paragraph. A MESSAGE COUNT communicate issued for a Queue 
that is marked as being at END“-OF“FILE will show the EOF status 
as a pseudo“message ~ the count for that particular Queue File 
wilt be one more than the count of real messages- When the 
reader executes a specific READ on the member Queue which is = at 
EQF» the EOF branch wild be taken. The next MESSAGE.COUNT will 
Show the member Queue as containing no messages» Another READ on 
the member will result in the EOF branch being taken agains as is 
done for a singtie Queue File. 


On Queue WRITE operations» END“DF°“FILE is not defined and wilt 
never occurs» EXCEPTION has the same meaning as it does for READ 
operations ~ it denotes an invalid key condition on Queue File 
Families onty. INCOMPLETE“IO will be reported» if requested» 
when the Queue is full and there is no space available to store 
the message that is being written. If no INCOMPLETE“I0 report is 
rquested and the Queue is full when a WRITE occurs» the progran 
is suspended until space is available in the Queue. 


As mentioned previously» when a togical I/0 request is directed 
to a Queue File Family» a key must be included to identify the 
specific Queue in the family to which the operation is directed. 


This is similar to Switch Files in the SDL Language. Family 
meabers are nuabered fogicaily from one to ne Giving a key of 
zero on a READ is defined as an unspecified read. The members 
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will be searched» beginning with number ones and the first queue 
meaber found not empty wilt be read. <A key of zero on a write is 
invalid. 


HRETING 10 THE TOP GE A QUEUE FILE 


Writing to the top of a Queue File is allowed in the MCP though 
it may or may not be allowed in a given  tanguage. A message 
written to a queue file normatly goes to the bottom of the Queue 
though some rare occurrences in applications may require’ the 
converse. This capability is invoked in the communicate 
operation by setting Dit 7 of CTADVERS. 


MESSAGE:COUNT COMMUNICATE 


This communicate operation returns the count of messages in the 
Queue File specified. If a Queue File Family is specified» the 
count of each member witl be returned in an array (member one in 
the first position» member two in the second» etc)» up to the 
liait of the result field. Counts wilt be returned either in 
decimai (COBOL "PICTURE 999") or binary CSDL *BITCZ243") depending 
on the value of the first bit of CT.ADVERB. This operation may 
not be jiaplLemented in atl lLanguages-s 


Format: 
CT»VERB 48 CHEX 9302) 
CT.aOBJECT File Number 
CTe-ADVERB BIT 1 Decimat format results if true 
CY.i Result field length in bits 
CT.2 Resuit fieid address 
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Figure 8°13 Two Programs Communicating in a Queve File Catted "MY.Q*. 
The Queue contains three messages. 
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Figure 872: A Queuerfile Family with three members. 
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INTERTPROGRAM COMNUNICATION 


Another means of acconplishing interprocess communication is the 
Inter“Program Communication Modules first implemented in the 920 
software to satisfy the requirements of the ANSI "74 COBOL 
Language. According to the specifications of that Language» the 
facility provides synchronous CALL and EXIT verbse as well as a 
shared data implementation. The module provides a facility to 
transfer control from one prograa to another and the ability for 
both programs to have access to the same data items. The names 
of the programs to which control is to be passsed may or may not 
be known at compite timee Additionally» this module provides the 
ability to determine the availability of memory for the program 
to which control is being passedwj — 


RUN UNIT DEFINITION 


The definition of a "Run Unit™ is critical to the implementation 
of the CALL/CANCEL wmechanisa described in the ANSI *"74& COBOL 
specifications. The execution of any program via an EXECUTE 
control instruction does not establish a Run Unite <A Run Unit is 
established oniy when an executed program initiates another 


program via the CALL comagunicate. That called program is now a 
member of the Run Unit associated with the program that was 
originatly executed. Sinitarty» any program called by a program 


within the Run Unit becomes part of that Run Unit and remains in 
that Run Unit until terminated or cancetted. A job cannot be a 
member of more than one run unite The following figure 
represents seven programs CA - G) which have been called within a 
run unit. 


A CA was Executed) 
| 
{| <-"-" Current Path 
B 
» \ 
Previous “""*> . \ 
Path D Cc 
@ r ! 
2 ° 1 
F G E 


The connecting Links are generated by and represent the tast used 
path» and the tink exists untit a return CEXIT PROGRAM) is 
accomplished» Once a calted program has been exited (Dr Fs» 4G)» 
it remains suspended in its current state. The only path that is 
of interest is the path last traversed. 


8-10 


B1000 MCP MANUAL 
MARK 10.0 


The current path is important in order to check the validity of a 
CALL or CANCEL statement; if a program tries to CALL or CANCEL 
itself or any of its predecessors» the entire run unit will be 
DS*ed. The other finks are unimportants as any program in the 
run unit can CALL or detete other existing procrams» With the 
previously mentioned exceptions» or can CALL new programs. 


If» for examples program "E" canceis program *D* then the Run 
Unit would consist of aid of the following programs and appears 
ass 


Unattached 
Programs 
Fe G 


a ee ee see a eh. 


A CALL to any of these programs will resutt in a transfer of 
controt to the existing state» whereas a CALL to any other 
program» including *D*%» will cause an initial state copy to be 
invoked before control is transferred» The terminatione via STOP 
RUN or ABORT» of any program in a Run Unit will result in the 
removal of all programs in that Run Unit from memory. 


Te€ INPLEMENTATION OF SHARED DAIA 


For those not familiar with the ANSI "74 COBOL definition of 
Inter~Program Communications ald programs within a Run Unit 
execute synchronously. No two programs in a Run Unit may be 
executing simuditaneously at any time and consequently» there are 
no problems associated with two or more programs contending for 
the use of shared data. Controt is passed to a program via the 
CALL verbe The program which contains the CALL will not be 
allowed to execute again until the called program performs an 
EXIT PROGRAM verb. 


The calling program may specify one or more data items to which 


the calied program has accesse The shared data may be any 01 or 
77 devel item described in the calling program This includes 
items whose addresses have been received through a CALL. The 


data items may be named and defined differently in each program 
as tong as the length of the ittem remains the same in each 
program. This mechanisa is stricly a “pass by name" facility. 
Parameters cannot be passed by value. Additionally» storage for 
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the shared data is never aliocated in the cailed program. In 
other words» the address of the data» onty» is always passed to 
the called progran. ) 


TPE RUN STRUCTURE NUCLEUS CHANGES 


In order to maintain adil of the necessary information regarding 
the programs which comprise a Run Units severat fields were added 
to the Run Structure Nucleuse RS»NUCLEUS» the field in memory 
which contains information about each program that is executing», 
in the 9.0 version of the MCP. This field» as it has atways 
been»p is shared by the Operating System and the user program's 
interpreter. The fotlowing is a list of the fields which were 
added in the 9.20 version and a brief description of each. 


Ro2RUNSUNIT BITC16) 


When a job initiates a CALL» he establishes a RUN UNIT. This Run 
Unit is identified by his own (Cthe originator's) job number. 
RS »-RUNUNIT» for any job in the Run Unit» wiil cantain the job 
number of the programa which initiated the Run Unite 


RSsRUNeUNETeLINK BITC16) 


This field witt contain zero for the job that initiated the run 
unit and for any job in the Run Unit that has done an EXIT 
PROGRANe For any job that is currently active in the Run Unite a 
job that has not done an EXIT» this field witli contain the job 
nuaber of his cadiere 


RoelTPCeDICT BLTC24) 


This field witt contain the absolute address of the 
IPC-DICTZIGONARY through which parameters will te accessed within 
the calling job*s base~limit space. The fietd will be zero if 
the dictionary does not exist. This is the tist of parameters 
that this. job will passe The IPC.DICTIONARY is adjacent to the 
RS»NUCLEUS and found only in the callers Run Structure Nucleus. 
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R52LPCePARAMETERsL ISI BIIC24) 


This field will contain the absolute address of the 
IPC.PARAMETER.LIST. This space witt be adjacent to the Run 
Structure Nucteus for any caited job that can receive parameters. 
The ITPC.~PARAMETER»~LIST witl be a series of 24 bit fields. The 
first field witt contain the number of parameters that this job 
is capable of receiving. The remaining fields in the list witt 
contain the length in bits of each parameter. This tist is built 
only for the called program from the IPC.ePARAMETER-LIST in the 
called program's code file that is generated by the compiter. If 
the job cannot receive parameters» this field wid contain zero. 


RoelPCaDICTeSIZE BITC162 


This field will contain the number of entries in this program's 
IPC Dictionary. 


RSsEXECUTE TYPE BIIC4) 
/ 


This field is used to store the type of execution that originated 
the job. If the job is not an Execute type or a Call type» then 
it cannot be cadied» The field can contain the following values? 


Execute 

Compile and Go 

Coapite for Syntax 

Coampide to Library 

Compile and Save 

Go Part of Compile and Go 
Go Part of Compile and Save 
Call 


Sw Ue WN ee 
found # Wu oR a 


RR2NAME CHARACTERC302 


This field witl contain the name of this programe In the case of 
compilations» denoted by he value of the previous field» it will 
contain the name of the compiler as welt. 
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RS2lALLERSeLR BITC24) 


This field wild contain the Limit Register of this job"s caller. 


Ri2IPCeEVENT BIT Cid 


This field is a dummy event for any IPC hang or suspension of 
executions If a programa is waiting on RS.~IPC.~EVENT and is 
currently passives which will be indicated ty a zero value in 
RSeRUNeUNIT»LINK» the RSeSTATUS will be set to a yalue_ to 
indicate "Waiting to be Caaled™. If the program is currently 
actives indicated by a nonzero value in RSe«RUN-UNIToLINKs the 
RSeSTATUS wilt be set to a value indicating "Waiting on calied 
prograna™. 


RS2CANCELED BIICL2 


If this bootean is trues then at least one CANCEL communicate has 
been issued against this program. When this is true» this 
particular job is effectively no longer a member of the Run Unit 
and is waiting to be terminated by the SMCP. 


GPE Program Parameter Biock Changes 


It was also necessary to make changes in the Program Parameter 
Block» the twossector field that is generated by the compilers 
and stored in the code file> to accomodate the IPC 
inplementation. A tlist of the fields that have been added is 
presented belowe 


PROGsTPC-SizE BIICI6) 


This fieid indicates the numsber of entries in the 
IPC »PARAMETER.~LIST. If this field is not equal to zero» it 
indicates to the MCP that this program can only be called - it 
can never be EXECUTEd. 
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PROG-IPC-PIR BII(24) 


This field is used to store the relative disk address in the code 
file of the IPC.PARAMETER»LIST» The IPC.PARAMETER-LIST will be a 
series of 24 bit fields that contain the length in bits of the 
parameters that may be passed to this program with a CALL. 


PROGeTPCANAXs SENDePARAMS BITCI6) 


This field indicates the maximum nuaber of parameters to be 
passed by this program through a CALL» which will also be the 
number of entries in the IPC Dictionary. 


It was also necessary to add a field to the fornat of the Program 
Parameter Biock that is used by the MCP after the jobd is 
scheduted for executione This field» known as PPBeRUN.UNIT» is 
sixteen bits in Length and is used to contain the Job number of 
the run unit that this program will become a part of. 


LeC-DICTLONARY 


The IPC.DICTIONARY is a List of System Descriptors built by the 
program to describe the parameters to be passed on a CALL. This 
dictionary wild be within the space defined by RS.IPC.DICT in the 
RSeNUCLEUS of the calling programe The length of this dictionary 
is passed in the CALL communicate. The Micro MCP will verify 
that the number and length of parameters passed match the 
IPCePARAMETER.»LIST of the catled program. 
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TPC COMMUNICATE OPERATOR 


One new communicate operator was added to the Operating System to 
accomodate the IPC jimphementatione This operator is generated by 
the Compilers to implement the CALL» CANCEL and EXIT PROGRAM 
verbse It may be handled by the Micro MCP ocr the SDL MCP» 
depending upon the circuanstances. Its forsat is presented below 
and in the Demand Management section. 


CY»VERB 43 
CT.OBJECT 0 = CALL 
1 = CANCEL 
2 = EXIT PROGRAM CNo EOJ) 
CT.~ADVERB Bit 
0 - jf CALL» return on NO MEMORY 
imil - Not used 
CT.l Base relative address of a 30 character 
field that contains the name of the job 
to be cailed or cancelled. 
CT.2 Number of parameters to be passed 


RS»REINSTATEjM5SG.PTR values returned if requested: 


0 - Communicate coapleted as requested. 
1 - For CALL» insufficient memory to coaplete the CALL. 
- For EXIT PROGRAM» the program was initiated by an 
EXECUTE instruction as opposed to a CALL. 
= Not used for CANCEL. 


IPC Verb Qoeration 


One of the primary objectives of the IPC implementation was 
per formancee Therefores as much as possible of the IPC function 
was implemented in the Micro MCP. in the ANSI "74 COBOL 
Language» the CALL and CANCEL verbs require the speci fication of 
program names within the source text. On the 81000 system» the 
name of a program may be unknown to the user when the program is 
compiled» since the Run Unit may be executed under a Usercode. 


To simplify the task of associating program names with those 
specified by a program in a CALL or CANCEL communicater a new 
system structure was isplemented. A programmatic description of 
the structures IPC~RUNeUNIT~LIST» ts presented betow 
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O01 IPC~RUN-UNIT-LIST BITC320)» 
02 IPC~RUN.~UNIT.» NUMBER BIT (€16)» 
02 IPC.~PGM.~NAME CHARC30)>» 
02 IPC.PGM.JOBeNUMBER |. BIT €16)>» 
02 IPC.ePGMeLR BIT (€24)» 
02 IPC.~FORWARD»LINK BIT €24)s 


IPCeRUNUNIToLIST is a tinked serial tist which includes all 
members of all Run Units. The entries in this list aren*t in any 
particular order and are not grouped by Run Unit. The SDL 
portion of the MCP is responsible for the management’ and 
maintainence of att IPC.RUN~UNIT.-LISTS~ The first 
IPCeRUNeUNITeLISY is addressed by a field in the MCP"s 9 stack. 
Both the SeMCP and the Micro MCP €M.MCP) access these structures 
for informations 


Tec CALL OPERATION 


The MICRO MCP receives ali CALL communicates. Any named job is 
considered a candidate for a CALL by the Micro MCP. If the 
requested job is not currentiy a member of the correct Run Unit» 
then the CALL request will be transferred from the Micro MCP to 
the SDL portion of the MCP» to make the called program present. 


To determine if the requested job is a member of the correct Run 
Unite the Micro MCP searches the List of Run Units» beginning 
With the first» which is addressed by a field in the MCP stacks» 
Each program that is a member of any Run Unit will be found in 
the serialty tink tist described by the IPC.RUN.UNIT.LIST 
structuree 


If the program is present» the Micro MCP wild first examine the 
program*s RS.CANCELED boolean in its Run Structure Nucleus. If 
this boolean is trues then this copy of the program has been 
cancelled and a new copy must be initiated. CANCEL operations» 
Like ali program termination operations do not happen 
fjamediately.»j If anew copy must be initiated» the Micro MCP will 
call the S»NCP to initiate a new copy of the same programe SeMCP 
operationss upon receiving a CALL communicate» are described in 
later paragraphs. 


If the RS»CANCELLED boolean is false» then the Micro MCP checks 
to determine whether the caiied job is active or passives which 
wilt be indicated by the RSeRUNUNITe-LINK field of the Run 


Structure Nucleus» If the job is ailready actives then some 
theoreticatly impossible error has occurred and the Micro MCP 
must call the S MCP so that the Run Unit can be terminated. If 
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the called program is found to be passive» then the Micro MCP 
will next check to insure that the number of parameters to be 
passed» if any» agree. This will. be indicated by the calling 
program's RS.~IPC.DICT field being equal to the catied program's 
IPCePARAMETER*LISTo 


: ( 

If the number of parameters do not match» then the Micro MCP 
calis the SeMCP for termination of the run unite If the number 
of parameters do agrees the Nicro MCP next checks to insure that 
the length specified for each passed parameter is the same in the 
calling program and the catled program. If any of the length 
descriptions are not equat» the Micro NCP will cali the S.MCP for 
termination of the entire Run Unite 


If parameters are being passed» if the number of parameters is 
equal and if they all have equal tength attributes» then in the 
calling program's Run structure Nucleus» the Micro MCP increments 
the RS»TEMPORARY»FREEZE fields to fix the program in memory = and 
sets the RSweRUNeUNITeLINK field to the caller's job number. In 
the Run Structure Nucieus of the caited jot» it sets the 
RSeCALLERS-LR field to the Limit register of the calling programe 
It then hangs the calling program on its RS~IPC.EVENT fieid and 
sets the cadler*s RS-STATUS field to “waiting on the calied 
program” and marks the calied job “ready to run". It should be 
noted that it is not necessary to freeze the calling program in 
memory if pararweters are not passede 


Considering the case where the called program is not a member of 
the Run Unit and the S-MCP is catlied upon to execute the 
requested programs whenever the S.MCP receives a CALL communicate 
and usercodes are involved» it will first search the List of Run 
Unitss using alt permutations of the userroded names to determine 
if the job exists in the Run Unit under a different name. if so» 
the new name and corresponding information will be entered into 
the Run Unit List and control wilt be returned to the Micro MCP. 
If Usercodes are not involved and if the name does not exist in 
the Run Unit Lists» then execution of the job must be attempted. 


The S.MCP must then determine that the requested program is 
present on diske If not presents» the program which issued” the 
CALL will be hung until the requested program is made present. 
If the requested program is present on disks the SeMCP must then 
determine that there is enough memory to execute the requested 
programe If there is insufficient memory» The program which 
performed the CALL may have asked to be notified of this fact. 
If soe the called job will not be scheduled but the program which 
performed the CALL will be notified of the insufficient memory 
condition. If the program which performed the CALL did not 
request to be nofitied»s the catted program will be scheduled and 
the catling program will not be atllowed to execute until the 
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called program does an EXIT PROGRAM communicate. 


Actually» after the cailed program reaches BOJ» the 5SeMCP will 
hang the called program on his own RSeIPCeEVENT with RS»STATUS 
set to "“Wdaiting to be cailed™ and put the caiting program back in 
the MeCOMM.Q. This allows the Micro MCP to complete the CALL 
operations 4 


TPC CANCEL QPERATION 


Ali aspects of the CANCEL and EXIT PROGRAM communicate opertors 
are handled by the Micro MCP. Upon receiving a CANCEL operator» 
the Micro MCP must first determine if the job exists in the Run 
Unit and whether it is active or passives If it is not present 
or the program is present but its RS»CANCELED boolean is trues 
the request is ignored and the cancelling job is reinstated. If 
it is present and passive» the Micro MCP will then place the 
specified program in the EXTERMINATE.Q@» set the RS»CANCELED 
boolean and return control to the job which issued the 
communicate. The EXTERMINATE.Q will cause termination of the 
jobe 


A request to CANCEL a job that is both a member of the Run Unit 
and active is a violation of the COBOL specifications and witt 
result in termination of the entire Run Unit. 


TEC EXIT PROGRAM OPERATION 


If a catied job issues an EXIT PROGRAM communicate operation» the 
Nicro MCP will hang the issuing program on its RS»IPCAEVENT 
fieid» setting RSeSTATUS to "Waiting to be caited"» decrement 
RSeTEMPORARY.FREEZE in the Run Structure Nucteus of the program 
that called the issuing program and mark the calling progran 
ready to rune If a program that was not cadtled issues the 
communicates the communicate wilt be ignored and controt wiit be 
immediately returned to that program. 


IPC TERMINATION CONSIDERATIONS 


If any program in a Run Unit performs a STOP RUN communicate 
operators the entire Run Unit will be canceiled and ati programs 
in the Run Unit will be discontinued.j Simitarly» if any prograr 
in the Run Unit terminates abnormally» the entire Run Unit wilt 
be discontinued. Programs within a Run Unit may only stop 
execution via the EXIT PROGRAM verb. Normal termination will 
occur when the program that initiated the Run Unit terminates. 
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Upon terminations for any reasons of any member of a particular 
Run Unite the $-NCP witt immediately delink alt entries 
pertaining to the specified Run Unit from the Run Unit List. 
When the parent of a Run Unit goes to a normal EDJ» then all jobs 
attached to that run unit wilt be cancelled. If any job in a run 
unit is aborted» then the entire run unit will be aborted. If 
one program in a Run Unit does a CANCEL on another program in the 
same run units then the cancelled job must be delinked froa the 
run unit and sent to EQJ. 


IPC MICRO MERZSeNCP COMMUNICATION 


The transfer of information between the Micro MCP and the SeMCP 
is accomplished using an existing mechanisa. This mechanisr 
utilizes the Run Structure Nucteus field» RSeM-ePROBLEN. Ail 
instances of such required communication are shown in the 
following table. The table shows the value that wild be stored 
in the RSeMNPROB»P2 fieids a subfietd of RSeN»PROBLEN» the 
condition that caused the communication and the action that wiiid 
be taken by the S.-MCP. Whenever such communication is necessary» 
the RSeMPROB»P1 field» also a subfields will be set to a value of 
9> which wild indicate the family of probiems related to [PC. 


RS-MPROB~P2 = Error Description Required Action 

0 Requested program not S.MCP should make 
not in mix program present. 

1 Number of parameters SeMCP will DS entire 
do not matche Run Unite 

2 Parameter specse SeNCP wilt DS entire 
do not agree. Run Unit. 

3 Attempted recursive SeMCP wilt DS entire 
CALL Run Unit. 

4 Attempted CANCEL SeMCP wild DS entire 
of predecessors Run Unit. 

5 Invalid Communicate SeMCP wild DS entire 
parameters. Run Unit. 

6 Found requested job Terminate specified 
and RS.CANCELED true | job and make new 


copy present. 
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TEC PROGRAM DUMPS 


If any member of the Run Units regardless of whether the 
specified program is active or passive is DS~eds DP~ed» or DM~ed» 
the entire Run Unit wilt be dumped and» if DSed or DP ed» 
terminated. 


TPC CANDIDATES FOR ROLL=QUT 


After the Micro MCP processes an IPC communicates it wilt not 
purposely mark the appropriate job TO.BE.ROLLED.OUT. If the 
SeNCP needs memory» tt wilt follow the normal selection process 
in determining a candidatefs) for Roltrout. There will be no 
special consideration given to members of Run Unitse 


TPO TASK CONSITOERATIONS 


Each called program witt actualiy become a TASK associated with 
the originator of the Run Unit. By becoming a TASK as opposed to 
anormal jobs» several advantages will be realized. 


1) TASKS are not subject to MIX Limits and other scheduling 
constraints. 
2) There witli be corresponding entries in the SYSTEM/LOG. 


TPC PROGRAM NAME SPECIFICATIONS 


Information passed for the programs name in the CALL/CANCEL 
communicate will be subject to the same naming restrictions as a 
file with respect to DS or DP conditions» eege» CALLing a program 
With a blank MFID wili result in the termination of the entire 
Run Unite 
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